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Preface 

Like  any  human  language,  C++  provides  a way  to 
express  concepts.  If  successful,  this  medium  of  ^ 
expression  will  be  significantly  easier  and  more  flexible 
than  the  alternatives  as  problems  grow  larger  and  more 
complex. 


You  can't  just  look  at  C++ as  a col  lection  of  features;  some  of  the 
features  make  no  sense  in  isolation.  You  can  only  use  the  sum  of 
the  parts  if  you  are  thinking  about  cfes/gin,  not  simply  coding.  And 
to  understand  C++ this  way,  you  must  understand  the  problems 
with  C and  with  programming  in  general.  This  book  discusses 
programming  problems,  why  they  are  problems,  and  the  approach 
C++  has  taken  to  solve  such  problems.  Thus,  the  set  of  features  I 
explain  in  each  chapter  will  be  based  on  the  way  that  I see  a 
particular  type  of  problem  being  solved  with  the  language.  In  this 
way  I hope  to  move  you,  a little  at  a time,  from  understanding  C to 
the  point  where  the  C++ mindset  becomes  your  native  tongue. 

Throughout,  I'll  betaking  the  attitude  that  you  want  to  build  a 
model  in  your  head  that  allows  you  to  understand  the  language  all 
the  way  down  to  the  bare  metal;  if  you  encounter  a puzzle,  you'll 
beabletofeed  itto  your  model  and  deduce  the  answer.  I will  try  to 
convey  to  you  the  insights  that  have  rearranged  my  brain  to  make 
me  start  "thinking  in  C++." 


What's  new  in  the  second  edition 

This  book  is  a thorough  rewrite  of  thefirst  edition  to  reflect  all  of 
the  changes  introduced  in  C++ by  the  finalization  of  theC++ 
Standard,  and  also  to  reflect  what  I've  I earned  si  nee  writing  the 
f i rst  ed  i ti  on . The  enti  re  text  present  i n the  f i rst  ed  i ti  on  has  been 
examined  and  rewritten,  sometimes  removing  old  examples,  often 
changing  existing  examples  and  adding  new  ones,  and  adding 
many  new  exercises.  Significant  rearrangement  and  re-ordering  of 
the  material  took  place  to  reflect  the  avail  ability  of  better  tools  and 
my  improved  understanding  of  how  people  learn  C-H-.  A new 
chapter  was  added  which  is  a rapid  introduction  to  the  C concepts 
and  basic  C-H-featuresfor  those  who  don't  have  the  C background 
totackletherestof  thebook.  TheCD  ROM  bound  into  the  back  of 
the  book  contains  a seminar  that  is  an  even  gentler  introduction  to 
theC  concepts  necessary  to  understand  C-H-(orJava).  It  was 
created  by  Chuck  Allison  for  my  company  (M  indView,  Inc),  and 
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it's  cal  led  "Thinking  in  C:  Foundations  for  Java  and  C++."  It 
i ntroduces  you  to  the  aspects  of  C that  are  necessary  for  you  to 
move  on  to  C ++  or  J ava,  I eavi  ng  out  the  nasty  bits  that  C 
programmers  must  deal  with  on  a day-to-day  basis  but  that  the 
C-H- and  Java  languages  steer  you  away  from  (or  even  eliminate,  in 
the  case  of  Java). 

So  the  short  answer  to  the  question  "what's  different  in  the  2^^ 
edition?"  is:  what  isn't  brand  new  has  been  rewritten,  sometimes  to 
the  point  where  you  wouldn't  recognize  the  original  examples  and 
material. 

What's  in  Volume  2 of  this  book 

The  completion  of  the  C-H- Standard  also  added  a number  of 
important  new  libraries,  such  asstringand  the  containers  and 
algorithms  in  the  Standard  C-H- Library,  as  well  as  new  complexity 
i n tempi  ates.  These  and  other  more  advanced  topi  cs  have  been 
relegated  to  Volume  2 of  this  book,  including  issues  such  as 
multi  pie  inheritance,  exception  handling,  design  patterns,  and 
topics  about  building  and  debugging  stable  systems. 

How  to  get  Volume  2 

Just  I ike  the  book  you  currently  hold.  Thinking  in  C++,  Voiume2\5 
downloadable  in  its  entirety  from  my  Web  site  at 
WWW. BruceEckd. com. 'To\j  can  find  information  on  the  Web  site 
about  the  expected  print  date  of  Volume  2. 

TheWeb  site  also  contains  the  source  codefor  both  of  the  books, 
along  with  updates  and  information  about  other  semi  nars-on-CD 
ROM  that  MindView,  Inc.  offers,  public  seminars,  and  in-house 
training,  consulting,  mentoring,  and  walkthroughs. 
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Prerequisites 

In  the  first  edition  of  this  book,  I decided  to  assume  that  someone 
else  had  taught  you  C and  that  you  have  at  least  a reading  level  of 
comfort  with  it.  My  primary  focus  was  on  simplifying  what  I found 
difficult:  the  C-H- language.  In  this  edition  I have  added  a chapter 
that  is  a rapid  introduction  to  C,  along  with  the  Thinking  in  C 
seminar-on-CD,  but  I am  still  assuming  that  you  already  havesome 
kind  of  programming  experience.  In  addition,  just  as  you  learn 
many  new  words  intuitively  by  seeing  them  in  context  in  a novel, 
it's  possible  to  learn  a great  deal  about  C from  the  context  in  which 
it  is  used  in  the  rest  of  the  book. 


Learning  C+  + 

I clawed  my  way  into  C++ from  exactly  the  same  position  I expect 
many  of  the  readers  of  this  book  are  in:  as  a programmer  with  a 
very  no-nonsense,  nuts-and-bolts  attitude  about  programming. 
Worse,  my  background  and  experience  was  in  hardware-level 
embedded  programming,  in  which  C has  often  been  considered  a 
high-level  language  and  an  inefficient  overkill  for  pushing  bits 
around.  I discovered  later  that  I wasn't  even  a very  good  C 
programmer,  hiding  my  ignorance  of  structures,  malloc(  )and 
free( ) setjmp(  )and  longjmp( ) and  other  "sophisticated  " 
concepts,  scuttling  away  in  shame  when  the  subjects  came  up  in 
conversation  instead  of  reaching  out  for  new  knowledge. 

When  I began  my  struggleto  understand  C-I-+,  the  only  decent 
book  was  BjarneStroustrup's  self-professed  "expert's  guide,i"  so  I 
was  left  to  si  mplify  the  basic  concepts  on  my  own.  This  resulted  i n 
my  first  C-H- book,2  which  was  essentially  a brain  dump  of  my 
experience.  That  was  designed  as  a reader's  guideto  bring 


^ Bjarne  Stroustrup,  TheC++  Programming  Language,  Addison-Wesley,  1986  (first 
edition). 

2 Using  C++,  Osborn^  McGraw-Hill  1989. 
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programmers  intoC  and  C++ at  the  same  time.  Both  editions^of 
the  book  garnered  enthusiastic  response. 

At  about  the  same  ti  me  that  U sing  C ++  came  out,  i began  teachi  ng 
theianguagein  seminars  and  presentations.  Teaching  C++ (and 
iater,Java)  became  my  profession;  i'veseen  nodding  heads,  biank 
faces,  and  puzzied  expressions  in  audiences  aii  over  the  worid 
since  1989.  As  i began  giving  i n-house trai ning  to  smaiier  groups  of 
peopie,  i discovered  something  during  the  exercises.  Even  those 
peopie  who  were  smiiing  and  nodding  were  confused  about  many 
issues,  i found  out,  by  creating  and  chairing  the  C++ and  Java 
tracks  at  the  Software  Deveiopment  Conference  for  many  years, 
that  i and  other  speakers  tended  to  givethetypicai  audience  too 
many  topics,  too  fast.  So  eventuaiiy,  through  both  variety  in  the 
audience  ievei  and  the  way  that  i presented  themateriai,  i wouid 
end  up  iosing  some  portion  of  the  audience.  Maybe  it's  asking  too 
much,  but  because  i am  one  of  those  peopie  resistant  to  trad itionai 
iecturing  (and  for  most  peopie,  i beiieve,  such  resistance  resuits 
from  boredom),  i wanted  to  try  to  keep  everyone  up  to  speed. 

For  a time,  i was  creating  a number  of  different  presentations  in 
fairiy  short  order.  Thus,  i ended  up  i earning  by  experi ment  and 
iteration  (atechniquethataiso  worksweii  in  C++ program  design). 
Eventuaiiy  i deveioped  a course  using  everything  i had  iearned 
from  my  teaching  experience,  ittackiestheiearning  probiem  in 
discrete,  easy-to-digest  steps  and  for  a hands-on  seminar  (the  ideai 
iearning  situation)  there  are  exercisesfoii owing  each  of  the 
presentations.  You  can  find  out  about  my  pubiic  seminars  at 
www.BruceEckd.com,  and  you  can  aiso  iearn  about  the  seminars  that 
i'veturned  into  CD  ROMs. 

The  first  edition  of  this  book  deveioped  over  the  course  of  two 
years,  and  the  materiai  in  this  book  has  been  road-tested  in  many 
forms  in  many  different  seminars.  The  feed  back  that  i 've  gotten 


^Using  C++ and  C++lnside&  Out,  Osborn^  McGraw-Hill  1993. 
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from  each  seminar  has  helped  me  change  and  refocus  the  material 
until  I feel  it  works  well  as  a teaching  medium.  But  it  isn't  just  a 
seminar  handout;  I tried  to  pack  as  much  information  as  I could 
within  these  pages,  and  structure  it  to  draw  you  through  onto  the 
next  subject.  More  than  anything,  the  book  is  designed  to  servethe 
solitary  reader  who  isstruggling  with  a new  programming 
language. 

Goals 

M y goal  s i n thi  s book  are  to: 

1.  Present  the  material  one  simple  step  at  a time,  so  the  reader 
can  easily  digest  each  concept  before  moving  on. 

2.  Use  examples  that  are  as  simple  and  short  as  possible.  This 
often  prevents  me  from  tackling  "real  world"  problems,  but 
I'vefound  that  beginners  are  usually  happier  when  they  can 
understand  every  detai  I of  an  example  rather  than  bei  ng 
impressed  by  the  scope  of  the  problem  it  solves.  Also,  there's 
a severe  I i mit  to  the  amount  of  code  that  can  be  absorbed  i n a 
classroom  situation.  For  this  I sometimes  receive  criticism  for 
usi  ng  "toy  exampi  es,"  but  I'm  w i 1 1 i ng  to  accept  that  i n favor 
of  producing  something  pedagogical ly  useful. 

3.  Carefully  sequence  the  presentation  of  features  so  that  you 
aren't  seeing  something  you  haven't  been  exposed  to.  Of 
course,  this  isn't  always  possible;  in  those  situations,  a brief 
introductory  description  will  be  given. 

4.  Give  you  what  I think  is  important  for  you  to  understand 
about  the  language,  rather  than  everything  that  I know.  I 
believe  there  is  an  "information  importance  hierarchy,"  and 
there  are  some  facts  that  95  percent  of  programmers  will 
never  need  to  know  and  that  would  just  confuse  them  and 
add  to  their  perception  of  the  complexity  of  the  language.  To 
take  an  examplefrom  C,  if  you  memorize  the  operator 
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precedence  table  (I  never  did),  you  can  write  clever  code.  But 
if  you  have  to  think  about  it,  it  will  confuse  the 
reader/  maintainer  of  that  code.  So  forget  about  precedence, 
and  use  parentheses  when  things  aren't  clear.  This  same 
attitudewill  betaken  with  some  information  in  theC++ 
language,  which  I think  is  more  important  for  compiler 
writers  than  for  programmers. 

5.  Keep  each  section  focused  enough  so  the  lecture  time  - and 
the  time  between  exercise  periods  - is  reasonable.  Not  only 
does  this  keep  the  aud i ence's  mi nds  more  acti  ve  and 
involved  during  a hands-on  seminar,  it  gives  the  reader  a 
greater  sense  of  accomplishment. 

6.  Provide  readers  with  a solid  foundation  so  they  can 
understand  the  issues  well  enough  to  move  on  to  more 
difficult  coursework  and  books  (in  particular.  Volume  2 of 
this  book). 

7.  I'vetried  not  to  use  any  particular  vendor's  version  of  C-H- 
because,  for  learning  the  language,  I don't  think  that  the 
detai  I s of  a parti  cu I ar  i mpl  ementati  on  are  as  i mportant  as  the 
language  itself.  Most  vendors'  documentation  concerning 
their  own  implementation  specifics  is  adequate. 

Chapters 

C-H-isa  language  in  which  new  and  different  features  are  built  on 
top  of  an  existing  syntax.  (Because  of  this,  it  isreferred  to  asa 
hybrid  object-oriented  programming  language.)  As  more  people 
pass  through  the  learni  ng  curve,  we've  begun  to  get  a feel  for  the 
way  programmers  move  through  the  stages  of  the  C-H- language 
features.  Because  it  appears  to  be  the  natural  progression  of  the 
procedu rally-trained  mind,  I decided  to  understand  and  follow  this 
same  path  and  accelerate  the  process  by  posing  and  answering  the 
questions  that  came  to  me  as  I learned  the  language  and  those 
questions  that  came  from  audiences  as  I taught  the  language. 
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This  course  was  designed  with  one  thing  in  mind:  to  streamiinethe 
process  of  i earning  C++.  Audience  feed  back  heiped  me  understand 
which  parts  were  difficuit  and  needed  extra  iiiumi nation,  in  the 
areas  in  which  i got  ambitious  and  inciudedtoo  many  features  aii 
at  once,  i came  to  know  - through  the  process  of  presenting  the 
materiai  - that  if  you  inciude  a iot  of  new  features,  you  have  to 
expiain  them  aii,  and  the  student's  confusion  iseasiiy 
compounded.  Asa  resuit,  i'vetaken  agreatdeai  oftroubieto 
introduce  the  features  as  few  at  a time  as  possibie;  ideaiiy,  oniy  one 
major  concept  at  a ti  me  per  chapter. 

The  goai,  then,  is  for  each  chapter  to  teach  a si  ngie  concept,  ora 
smaii  group  of  associated  concepts,  in  such  a way  that  no 
additionai  features  are  reiied  upon.  That  way  you  can  digest  each 
piece  in  the  context  of  your  current  knowiedge  before  moving  on. 
To  accompiish  this,  i i eave  some  C features  in  p i ace  for  ionger  than 
i wouid  prefer.  The  benefit  is  that  you  wiii  not  be  confused  by 
seeing  aii  the  C++ features  used  before  they  are  expiained,  so  your 
introduction  to  the  ianguage  wiii  begentieand  wiii  mirror  theway 
you  wiii  assimiiatethefeaturesif  iefttoyour  own  devices. 

Here  is  a brief  description  of  the  chapters  contai  ned  in  this  book: 

Chapter  1:  Introduction  to  ObjecC^hen  projects  became  too  big 
and  compiicated  toeasiiy  maintain,  the  "software crisis"  was  born, 
with  programmers  saying,  "We can't  get  projects  done,  and  if  we 
can,  they're  too  expensive!"  This  precipitated  a number  of 
responses,  which  are  discussed  in  this  chapter  aiong  with  the  ideas 
of  object-oriented  programming  (OOP)  and  how  it  attempts  to 
soi  ve  the  software  crisis.  The  chapter  wai  ks  you  through  the  basic 
concepts  and  features  of  OOP  and  aiso  introduces  the  anaiysi  sand 
design  process,  in  addition,  you'ii  iearn  about  the  benefits  and 
concerns  of  adopting  the  ianguage  and  suggestions  for  moving  into 
theworid  of  C-H-. 

Chapter  2:  Making  and  Using  ObjecShis  chapter  expiai  ns  the 
process  of  buii ding  programs  usi ng  compiiers  and  iibraries.  it 
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introduces  the  first  C++ program  in  the  book  and  shows  how 
programs  are  constructed  and  compiled.  Then  some  of  the  basic 
libraries  of  objects  aval  I able  in  Standard  C++ are  introduced.  By  the 
ti  me  you  fi  ni  sh  thi  s chapter  you 'I  I have  a good  grasp  of  what  it 
means  to  write  a C++ program  using  off-the-shelf  object  libraries. 

Chapter  3:  TheC  in  C+.+This  chapter  is  a dense  overview  of  the 
featu res  i n C that  are  used  i n C -H-,  as  wel  I as  a nu mber  of  basi  c 
features  that  are  aval  I able  only  in  C-H-.  It  also  introduces  the 
"make"  utility  that's  common  in  the  software  development  world 
and  that  is  used  to  build  all  the  examples  in  this  book  (the source 
code  for  the  book,  which  is  available  at  www.BruceEckd.com, 
contai  ns  makefi  les  for  each  chapter).  Chapter  3 assumes  that  you 
have  a solid  grounding  in  some  procedural  programming  language 
like  Pascal,  C,  or  even  some  flavors  of  Basic  (as  long  as  you've 
written  plenty  of  code  in  that  language,  especially  functions).  If  you 
find  this  chapter  a bit  too  much,  you  should  first  go  through  the 
Thinking  in  C seminar  on  the  CD  that's  bound  with  this  book  (and 
also  availableat  www.BruceEckei.com). 

Chapter  4:  Data  Abstract!  oit/lost  featu  res  in  C-h- revolve  around 
the  ability  to  create  new  datatypes.  Not  only  does  this  provide 
superior  code  organization,  but  it  laysthe  groundwork  for  more 
powerful  OOP  abilities.  You'll  see  how  this  idea  is  facilitated  by  the 
simple  act  of  putting  functions  inside  structures,  the  details  of  how 
to  do  it,  and  what  kind  of  code  it  creates.  You'll  also  learn  the  best 
way  to  organize  your  code  into  header  files  and  implementation 
files. 

Chapters:  Hiding  the  I mplementatiohou  can  decide  that  some 
of  the  data  and  f u ncti  ons  i n you r structu  re  are  u navai  I abl  e to  the 
user  of  the  new  type  by  making  them  private  This  means  that  you 
can  separate  the  underlying  implementation  from  the  interface  that 
the  client  programmer  sees,  and  thus  allow  that  implementation  to 
be  easily  changed  without  affecting  client  code.  The  keyword  ciass 
isalso  introduced  asafancier  way  to  describea  new  datatype,  and 
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the  meaning  of  theword  "object"  isdemystified  (it'safancy 
variable). 

Chapters:  Initialization  and  Cleanu^ne  of  the  most  common  C 
errors  results  from  uninitialized  variables.  The  constructor  in  C++ 
allows  you  to  guaranteethat  variables  of  your  new  datatype 
("objectsof  your  class")  will  always  be  initialized  properly.  Ifyour 
objects  al  so  requ  i re  some  sort  of  cl  eanu  p,  you  can  guarantee  that 
this  cleanup  will  always  happen  with  the  C++ destructor. 

Chapter?:  Function  Overloading  and  Default  A rgumeiftsH- is 

intended  to  help  you  build  big,  complex  projects.  Whiledoing  this, 
you  may  bring  in  multi  pie  libraries  that  use  the  same  function 
name,  and  you  may  also  choose  to  use  the  same  name  with 
different  meanings  within  a single  library.  C++ makes  this  easy 
with  function  overloading,  which  allowsyou  to  reuse  the  same 
function  name  as  long  as  the  argument  lists  are  different.  Default 
arguments  allow  you  to  cal  I the  same  function  in  different  ways  by 
automatically  providing  default  values  for  some  of  your 
arguments. 

Chapter  8:  ConstantsThis  chapter  covers  the  constand  volatile 

keywords,  which  have  additional  meaning  in  C++,  especially 
inside  classes.  You'll  learn  what  it  means  to  apply  constto  a pointer 
definition.  The  chapter  also  shows  how  the  meaning  of  constvaries 
when  used  inside  and  outside  of  classes  and  howto  create  compi  I e- 
ti  me  constants  i nsi  d e cl  asses. 

Chapter  9:  Inline  Functions’ reprocessor  macros  eliminate 
function  call  overhead,  but  the  preprocessor  also  eliminates 
valuable  C++ type  checking.  The  inline  function  gives  you  all  the 
benefits  of  a preprocessor  macro  pi  us  al  I of  the  benefits  of  a real 
function  call.  This  chapter  thoroughly  explores  the  implementation 
and  use  of  inline  functions. 

Chapter  10:  NameControCreating  names  is  a fundamental 
activity  in  programming,  and  when  a project  gets  large,  the  number 
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of  names  can  be  overwhelming.  C++ allows  you  a great  deal  of 
control  over  names  in  terms  of  their  creation,  visibility,  placement 
of  storage,  and  linkage.  This  chapter  shows  how  names  are 
controlled  in  C++ using  two  techniques.  First,  the  static  keyword  is 
used  to  control  visibility  and  linkage,  and  its  special  meaning  with 
classes  is  explored.  A far  more  useful  technique  for  controlling 
names  at  the  global  scope  is  C++'snamespacefeature,  which 
allows  you  to  break  up  the  global  name  space  into  distinct  regions. 

Chapter  11:  References  and  the  Copy-Constructdi++ pointers 
worklikeC  pointers  with  the  additional  benefitof  stronger  C++ 
type  checking.  C++ also  provides  an  additional  way  to  handle 
addresses:  from  Algol  and  Pascal,  C++ lifts  the  reference,  which  lets 
the  compiler  handle  the  address  manipulation  whileyou  use 
ordinary  notation.  You'll  also  meet  the  copy-constructor,  which 
controls  the  way  objects  are  passed  into  and  out  of  functions  by 
value.  Finally,  theC-H-pointer-to-member  is  illuminated. 

Chapter  12:  Operator  Overloadin§'hisfeatureissometimes 

called  "syntactic  sugar;"  it  lets  you  sweeten  the  syntax  for  using 
you  r ty pe  by  al  I ow  i ng  operators  as  wel  I as  f u ncti  on  cal  I s.  I n th i s 
chapter  you'll  learn  that  operator  overloading  is  just  a different 
type  of  function  call  and  you'll  learn  how  to  write  your  own, 
dealing  with  the  sometimes-confusing  uses  of  arguments,  return 
types,  and  the  decision  of  whether  to  make  an  operator  a member 
or  friend. 

Chapter  13:  Dynamic  Object  CreatioMow  many  planes  will  an 
ai  r-traffi  c system  need  to  manage?  H ow  many  shapes  wi  1 1 a CA  D 
system  require?  In  the  general  programming  problem,  you  can't 
know  the  quantity,  lifetime,  or  type  of  objects  needed  by  your 
running  program.  In  this  chapter,  you'll  learn  how  C-F+'snewand 
deleteelegantly  solvethis  problem  by  safely  creating  objects  on  the 
heap.  You'll  also  see  how  new  and  deletecan  be  overloaded  in  a 
variety  of  ways  so  you  can  control  how  storage  is  allocated  and 
released. 
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Chapter  14:  Inheritance  and  CompositioBata  abstraction  allows 
you  to  create  new  types  from  scratch,  but  with  composition  and 
inheritance,  you  can  create  new  types  from  existing  types.  With 
composition,  you  assemble  a new  type  using  other  types  as  pieces, 
and  with  inheritance,  you  create  a more  specific  version  of  an 
existing  type.  In  this  chapter  you'll  learn  the  syntax,  howto 
redefine  functions,  and  the  importance  of  construction  and 
destruction  for  inheritance  and  composition. 

Chapter  15:  Polymorphism  and  virtual  Functioifin  your  own, 
you  mighttake  nine  months  to  discover  and  understand  this 
cornerstone  of  OOP.  Through  small,  simple  examples,  you'll  see 
how  to  create  a family  of  types  with  inheritance  and  manipulate 
objects  in  that  family  through  their  common  base  class.  The  virtual 
keyword  allows  you  to  treat  all  objects  in  this  family  generi  call  y, 
which  means  that  the  bulk  of  your  code  doesn't  rely  on  specific 
type  information.  This  makes  your  programs  extensible,  so 
building  programs  and  code  maintenance  is  easier  and  cheaper. 

Chapter  16:  Introduction  to Templatelsiheritance and 

composition  allow  you  to  reuse  object  code,  but  that  doesn't  solve 
all  of  your  reuse  needs.  Templates  allow  you  to  reuse  source  code 
by  providing  the  compiler  with  a way  to  substitute  type  names  in 
the  body  of  a class  or  function.  This  supports  the  use  of  container 
c/ass  libraries,  which  are  important  tools  for  the  rapid,  robust 
development  of  object-oriented  programs  (the  Standard  C-h- 
Library  includes  a significant  library  of  container  classes).  This 
chapter  gives  you  a thorough  grounding  in  this  essential  subject. 

Additional  topics  (and  more  advanced  subjects)  are  available  in 
Volume2of  this  book,  which  can  bedownloaded  from  the  Web  site 
www.BruceE  ckd.  com . 
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Exercises 

I've  discovered  that  exercises  are  exceptionally  useful  during  a 
senninar  to  complete  a student's  understanding,  so  you'll  find  aset 
at  the  end  of  each  chapter.  The  number  of  exercises  has  been 
greatly  increased  over  the  number  in  the  first  edition. 

Many  of  the  exercises  are  fairly  simple  so  that  they  can  be  finished 
in  a reasonable  amount  of  time  in  a classroom  situation  or  lab 
section  whilethe  instructor  observes,  making  sure  all  students  are 
absorbing  the  material.  Some  exercises  are  a bit  more  challenging  to 
keep  advanced  students  entertained.  The  bulk  of  the  exercises  are 
designed  to  be  solved  in  a short  ti  me  and  are  intended  only  to  test 
and  polish  your  knowledge  rather  than  present  major  challenges 
(presumably,  you'll  find  those  on  your  own  - or  more  likely,  they'll 
find  you). 

Exercise  solutions 

Solutions  to  selected  exercises  can  be  found  in  the  electronic 
document  TheThinking  in  C++ Annotated  Solution  Guide,  available 
for  a small  fee  from  www.BruceEckel.com. 

Source  code 

The  source  code  for  this  book  is  copyrighted  freeware,  distributed 
via  the  Web  site  www.BruceEckel.com.  The  copy  right  prevents  you 
from  republishing  the  code  in  print  media  without  permission,  but 
you  are  granted  the  right  to  use  it  in  many  other  situations  (see 
below). 

The  code  is  available  in  azipped  file,  designed  to  be  extracted  for 
any  pi atform  that  has  a "zip"  uti  I ity  (most  do;  you  can  search  the 
Internet  to  find  a version  for  your  platform  if  you  don't  already 
have  one  installed).  In  the  starting  directory  where  you  unpacked 
thecodeyou  will  find  the  following  copyright  notice: 
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//:!  : Copyright . txt 

Copyright  (c)  2000,  Bruce  Eckel 

Source  code  file  from  the  book  "Thinking  in  C++" 

All  rights  reserved  EXCEPT  as  allowed  by  the 
following  statements:  You  can  freely  use  this  file 
for  your  own  work  (personal  or  commercial), 
including  modifications  and  distribution  in 
executable  form  only.  Permission  is  granted  to  use 
this  file  in  classroom  situations,  including  its 
use  in  presentation  materials,  as  long  as  the  book 
"Thinking  in  C++"  is  cited  as  the  source. 

Except  in  classroom  situations,  you  cannot  copy 
and  distribute  this  code;  instead,  the  sole 
distribution  point  is  http://www.BruceEckel.com 
(and  official  mirror  sites)  where  it  is 
available  for  free.  You  cannot  remove  this 
copyright  and  notice.  You  cannot  distribute 
modified  versions  of  the  source  code  in  this 
package.  You  cannot  use  this  file  in  printed 
media  without  the  express  permission  of  the 
author.  Bruce  Eckel  makes  no  representation  about 
the  suitability  of  this  software  for  any  purpose. 

It  is  provided  "as  is"  without  express  or  implied 
warranty  of  any  kind,  including  any  implied 
warranty  of  merchantability,  fitness  for  a 
particular  purpose,  or  non-infringement.  The  entire 
risk  as  to  the  quality  and  performance  of  the 
software  is  with  you.  Bruce  Eckel  and  the 
publisher  shall  not  be  liable  for  any  damages 
suffered  by  you  or  any  third  party  as  a result  of 
using  or  distributing  this  software.  In  no  event 
will  Bruce  Eckel  or  the  publisher  be  liable  for 
any  lost  revenue,  profit,  or  data,  or  for  direct, 
indirect,  special,  consequential,  incidental,  or 
punitive  damages,  however  caused  and  regardless  of 
the  theory  of  liability,  arising  out  of  the  use  of 
or  inability  to  use  software,  even  if  Bruce  Eckel 
and  the  publisher  have  been  advised  of  the 
possibility  of  such  damages.  Should  the  software 
prove  defective,  you  assume  the  cost  of  all 
necessary  servicing,  repair,  or  correction.  If  you 
think  you've  found  an  error,  please  submit  the 
correction  using  the  form  you  will  find  at 
www.BruceEckel.com.  (Please  use  the  same 
form  for  non-code  errors  found  in  the  book.) 
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You  may  use  the  code  in  your  projects  and  in  the  classroom  as  long 
as  the  copyright  notice  is  retained. 


Language  standards 

Throughout  this  book,  when  referring  to  conformanceto  the  ISO  C 
standard,  I will  generally  just  say  'C.'  Only  if  it  is  necessary  to 
distinguish  between  Standard  C and  older,  pre-Standard  versions 
of  C will  I make  a distinction. 

Atthis  writing  the  C++ Standards  Committee  was  finished 
workingonthelanguage.  Thus,  I will  use  the  term  Standard  C++  to 
refer  to  the  standardized  language.  If  I simply  refer  to  C++ you 
should  assume  I mean  "Standard  C++." 

There  is  some  confusion  over  the  actual  name  of  the  C++ Standards 
Committee  and  the  name  of  the  standard  itself.  Steve  damage,  the 
committee  chair,  clarified  this: 

There  are  two  C ++  standardization  committees:  The  N CITS  (formerly 
X3)  J16  committee  and  the  ISO  JTCllSC22tWG14  committee.  ANSI 
charters  N CITS  to  create  technical  committees  for  developing 
A merican  national  standards. 

jl6  was  chartered  in  1989  to  create  an  A merican  standard  for  C ++.  In 
about  1991  WG14  was  chartered  to  create  an  international  standard. 
Thejld  project  was  converted  to  a "Typel"  (International)  project 
and  subordinated  to  the  I SO  standardization  effort. 

The  two  committees  meet  at  the  same  time  at  the  same  location,  and 
thejld  vote  constitutes  the  A merican  vote  on  WG14.  WG 14  delegates 
technical  work  to  j 16.  WG14  votes  on  the  technical  work  of  j 16. 

The  C++  standard  was  originally  created  as  an  ISO  standard.  ANSI 
later  voted  (as  recommended  by  jl6)  to  adopt  the  ISO  C ++  standard  as 
the  A merican  standard  for  C ++. 
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Thus,  'ISO'  isthecorrect  way  to  refer  to  the  C++ Standard. 


Language  support 

Your  compiler  may  not  support  all  of  the  features  discussed  in  this 
book,  especially  if  you  don't  havethe  newest  version  of  the 
compi  I er.  I mpl  ementi  ng  a I anguage  I i ke  C ++  i s a H ercu  I ean  task, 
and  you  can  expect  that  the  features  will  appear  in  pieces  rather 
than  all  at  once.  But  if  you  attempt  one  of  the  examples  in  the  book 
and  get  a lot  of  errors  from  the  compi  I er,  it's  not  necessari  ly  a bug 
i n the  code  or  the  compi  I er;  it  may  si  mpl  y not  be  i mpl  emented  i n 
your  particular  compiler  yet. 


The  book's  CD  ROM 

The  primary  content  of  the  CD  ROM  packaged  in  the  back  of  this 
book  is  a "seminar  on  CD  ROM"  titled  Thinking  in  C:  Foundations  for 
Java  & C++  by  Chuck  Allison  (published  by  MindView,  Inc,  and 
also  available  in  quantities  at  www.BruceEckd. conn). Thlscor^talns 
many  hours  of  audio  lectures  and  slides,  and  can  be  viewed  on 
most  computers  if  you  have  a CD  ROM  player  and  a sound  system. 

The  goal  of  Thinking  in  C isto  take  you  carefully  through  the 
fundamentalsof  theC  language.  It  focuses  on  the  knowledge 
necessary  for  you  to  be  abl  e to  move  on  to  the  C ++  or  J ava 
languages  instead  of  trying  to  makeyou  an  expert  in  all  thedark 
corners  of  C.  (One  of  the  reasons  for  using  a higher-level  language 
likeC-H-orJava  is  precisely  so  we  can  avoid  many  of  these  dark 
corners.)  It  also  contains  exercises  and  guided  solutions.  Keep  in 
mind  that  because  Chapter  3 of  this  book  goes  beyond  the  Thinking 
in  C CD,  the  CD  is  not  a replacement  for  that  chapter,  but  should  be 
used  instead  as  a preparation  for  this  book. 

Please  notethattheCD  ROM  is  browser- based,  so  you  should  have 
a Web  browser  installed  on  your  machine  before  using  it. 
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CD  ROMs,  seminars, 
and  consulting 

There  are  semi  nars-on-CD-ROM  planned  to  cover  Volume  land 
Volume  2 of  this  book.  These  comprise  many  hours  of  audio 
lectures  by  me  that  accompany  si  ides  that  cover  selected  material 
from  each  chapter  in  the  book.  They  can  be  viewed  on  most 
computers  if  you  have  a CD  ROM  player  and  a sound  system. 
These  CDs  may  be  purchased  at  www.BruceEckd.com,  where  you 
will  find  more  information  and  sample  lectures. 

My  company,  MindView,  Inc,  provides  public  hands-on  training 
seminars  based  on  the  material  in  this  book  and  also  on  advanced 
topics.  Selected  material  from  each  chapter  represents  a lesson, 
which  isfollowed  by  a monitored  exercise  period  so  each  student 
receives  personal  attention.  Wealso  provideon-site training, 
consulting,  mentoring,  and  design  and  code  walkthroughs. 
Information  and  sign-up  forms  for  upcoming  seminars  and  other 
contact  information  can  be  found  at  www.BruceEckd.com. 

I am  sometimes  avail  able  for  design  consulting,  project  evaluation 
and  code  walkthroughs.  When  I first  began  writing  about 
computers,  my  primary  motivation  was  to  increase  my  consulting 
activities,  because  I find  consulting  to  be  challenging,  educational, 
and  one  of  my  most  enjoyable  experiences,  professionally.  Thus  I 
will  try  my  besttofityou  into  my  schedule,  or  to  provideyou  with 
one  of  my  associates  (who  are  people  that  I know  well  and  trust, 
and  often  people  who  co-develop  and  teach  seminars  with  me). 


Errors 

N 0 matter  how  many  tricks  a writer  uses  to  detect  errors,  some 
always  creep  in  and  these  often  leap  off  the  page  to  a fresh  reader. 
If  you  discover  anything  you  believe  to  bean  error,  please  use  the 
correction  form  you  will  find  at  www.Bruc^ckd.com.  yo\jr  help  is 
appreciated. 
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About  the  cover 

The  first  edition  of  this  book  had  my  face  on  the  cover,  buti 
originaiiy  wanted  a cover  for  the  second  edition  thatwas  more  of  a 
work  of  art  i ike  the  Thinking  in  Java  cover.  For  some  reason,  C++ 
seems  to  me  to  suggest  Art  Deco  with  its  si  mpie  curves  and 
brushed  chrome,  i had  in  mind  something  i ike  those  posters  of 
ships  and  airpianes  with  theiong  sweeping  bodies. 

My  friend  Daniei  Wiii-Harris,  (i/i/i/i/n/.H//7/-H arr/s.com)  whom  i first 
met  in  junior  high  schooi  choir  dass,  went  on  to  becomeaworid- 
dass  designer  and  writer.  H e has  done  vi  rtuai  iy  aii  of  my  designs, 
inciuding  the  cover  for  the  first  edition  of  this  book.  During  the 
cover  design  process,  Daniei,  unsatisfied  with  the  progress  we  were 
making,  kept  asking  "How  doesthis  reiate  peopie to  computers?" 
We  were  stuck. 

On  a whim,  with  no  particuiar  outcome  in  mind,  heasked  me  to 
put  my  face  on  the  scanner.  Daniei  had  one  of  his  graphics 
programs  (Corei  Xara,  his  favorite)  "autotrace"  the  scan  of  my  face. 
As  he  describes  it,  "Autotracing  is  the  computer's  way  to  turn  a 
picture  into  the  kinds  of  iines  and  curves  it  reaiiy  iikes."  Then  he 
piayed  with  it  untii  he  had  something  that  iooked  iikea 
topographic  map  of  my  face,  an  image  that  might  be  the  way  a 
computer  couid  see  peopie. 

i took  this  image  and  photocopied  it  onto  watercoior  paper  (some 
coior  copiers  can  hand ie thick  stock),  and  then  started  creating  iots 
of  experi ments  by  adding  watercoior  to  the  image.  Weseiected  the 
ones  we  i iked  best,  then  Daniei  scanned  them  back  in  and  arranged 
them  into  the  cover,  adding  the  text  and  other  design  dements.  The 
whoie  process  happened  over  severai  months,  mostiy  because  of 
the  time  it  took  me  to  dothewatercoiors.  But  i'veespeciaiiy 
enjoyed  it  because  i got  to  parti ci  pate  in  the  art  on  the  cover,  and 
because  it  gave  me  incentive  to  do  more  watercoiors  (what  they  say 
about  practice  reaiiy  is  true). 
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Book  design  and  production 

The  book's  interior  design  was  created  by  Daniei  Wiii-Harris,  who 
used  to  piay  with  rub-on  ietters  in  junior  high  schooi  whiiehe 
awaited  the  invention  of  computers  and  desktop  pubiishing. 
However,  i produced  the  camera-ready  pages  myseif,  sothe 
typesetting  errors  are  mine.  Microsoft®  Word  for  Windows 
Versions  8 and  9 were  used  to  write  the  book  and  to  create  camera- 
ready  pages,  inciuding  generati ng  the tabie of  contents  and  index. 

(i  created  a COM  automation  server  in  Python,  caiied  from  Word 
VBA  macros,  to  aid  me  in  index  marking.)  Python  (see 
www.Python.org)  was  used  to  create  some  of  the toois  for  checking 
the  code,  and  wouid  have  been  use  for  the  code  extraction  tooi  had 
i discovered  iteariier. 

i created  the  diagrams  using  V i si o®-  thanks  to  Visio  Corporation 
for  creati  ng  a usefui  tooi . 

The  body  typeface  is  Georgia  and  the  headiines  are  in  Verdana.  The 
finai  camera-ready  version  was  produced  in  Adobe®  Acrobat  4 and 
taken  directiy  to  press  from  that  fiie-  thanks  very  much  to  Adobe 
for  creating  a tooi  that  aiiows  e-maiiing  camera-ready  documents, 
asitenabiesmuitipierevisionsto  bemadein  asingieday  rather 
than  reiying  on  my  iaser  printer  and  overnight  express  services. 
(Wefirst  tried  theAcrobat  process  with  Thinking  in  Java,  and  i was 
abieto  upioad  the  finai  version  of  that  book  to  the  printer  in  the 
U .5.  from  South  Africa.) 

The  HTML  version  was  created  by  exporting  the  Word  document 
to  RTF,  then  using  RTF2HTM  L {see http://www.sunpack.com/RTF/)  to 
do  most  of  the  work  of  theHTM  L conversion.  (Thanks  to  Chris 
Hector  for  making  such  a usefui,  and  especiaiiy  reiiabie,  tooi.)  The 
resuiting  fiies  weredeaned  up  using  a custom  Python  program 
that  i hacked  together,  and  theWM  Fs  were  converted  to  GiFs  using 
J A SC®  PaintShop  Pro  6 and  its  batch  conversion  tooi  (thanks  to 
J A SC  for  soiving  so  many  probiemsfor  me  with  their  exceiient 
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product).  The  col  or  syntax  highlighting  was  added  via  a Perl  script 
kindly  contributed  by  Zafir  Anjum. 
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1:  Introduction  to  Objects 

The  genesis  of  the  computer  revolution  was  in  a 
machine.  The  genesis  of  our  programming  languages 
thus  tends  to  look  like  that  machine. 
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But  computers  are  not  so  much  machi  nes  as  they  are  mi  nd 
amplification  tools  ("bicycles  for  the  mind,"  asSteveJobsisfond  of 
saying)  and  a different  kind  of  expressive  medium.  Asa  result,  the 
tools  are  begi  nni  ng  to  look  less  I i ke  machi  nes  and  more  I i ke  parts  of 
our  minds,  and  also  I ike  other  expressive  mediums  such  as  writing, 
painting,  sculpture,  animation,  and  filmmaking.  Object-oriented 
programmi  ng  i s part  of  thi  s movement  toward  usi  ng  the  computer 
as  an  expressive  medium. 

This  chapter  will  introduce  you  to  the  basic  concepts  of  object- 
oriented  programming  (OOP),  including  an  overview  of  OOP 
development  methods.  This  chapter,  and  this  book,  assume  that 
you  have  had  experience  in  a procedural  programming  language, 
although  not  necessarily  C.  If  you  think  you  need  more  preparation 
in  programming  and  the  syntax  of  C before  tackling  this  book,  you 
should  work  through  the  "Thinking  in  C:  Foundations  for  C-H-and 
Java"  training  CD  ROM,  bound  in  with  this  book  and  also  available 
at  www.BruceEckd.com. 

This  chapter  is  background  and  supplementary  material.  Many 
peopledo  not  feel  comfortable  wading  into  object-oriented 
programming  without  understanding  the  big  picture  first.  Thus, 
there  are  many  concepts  that  are  introduced  hereto  give  you  a 
solid  overview  of  OOP.  However,  many  other  people  don't  get  the 
big  picture  concepts  until  they'veseen  some  of  the  mechanics  first; 
these  people  may  become  bogged  down  and  lost  without  some 
code  to  get  their  hands  on.  If  you're  part  of  this  latter  group  and  are 
eager  to  get  to  the  specifics  of  the  language,  feel  free  to  jump  past 
this  chapter  - skipping  it  at  this  point  will  not  prevent  you  from 
writing  programs  or  learning  the  language.  However,  you  will 
want  to  comeback  here  eventually  to  fill  in  your  knowledge  so  you 
can  understand  why  objects  are  important  and  how  to  design  with 
them. 
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The  progress  of  abstraction 

All  programming  languages  provide  abstractions.  It  can  be  argued 
that  the  complexity  of  the  problems  you're  ableto  solve  is  directly 
related  to  the  kind  and  quality  of  abstraction.  By  "kind"  I mean, 
"What  is  it  that  you  are abstracti ng?"  Assembly  language  is  a small 
abstraction  of  the  underlying  machine.  Many  so-called 
"imperative"  languages  that  followed  (such  as  Fortran,  BASIC,  and 
C)  were  abstractions  of  assembly  language.  These  languages  are  big 
I mprovements  over  assembly  language,  but  their  primary 
abstraction  still  requires  you  to  think  in  termsof  the  structure  of  the 
computer  rather  than  the  structure  of  the  problem  you  are  trying  to 
solve.  The  programmer  must  establish  the  association  between  the 
machine  model  (in  the  "solution  space,"  which  is  the  pi  ace  where 
you're  modeling  that  problem,  such  as  a computer)  and  the  model 
of  the  problem  that  is  actually  being  solved  (in  the  "problem 
space,"  which  isthe  place  where  the  problem  exists).  The  effort 
required  to  perform  this  mapping,  and  the  fact  that  it  is  extrinsic  to 
the  programming  language,  produces  programs  that  are  difficult  to 
write  and  expensive  to  maintain,  and  as  a side  effect  created  the 
entire  "programming  methods"  industry. 

The  alternative  to  modeling  the  machine  isto  model  the  problem 
you're  trying  to  solve.  Early  languages  such  as  LISP  and  APL  chose 
particular  views  of  the  world  ("All  problems  are  ultimately  lists"  or 
"All  problems  are  algorithmic").  PROLOG  casts  all  problems  into 
chains  of  decisions.  Languages  have  been  created  for  constraint- 
based  programming  and  for  programming  exclusively  by 
manipulating  graphical  symbols.  (The  latter  proved  to  be  too 
restrictive.)  Each  oftheseapproachesisagood  solution  to  the 
particular  class  of  problem  they're  designed  to  solve,  but  when  you 
step  outside  of  that  domain  they  become  awkward. 

The  object-oriented  approach  goes  a step  farther  by  providing  tools 
for  the  programmer  to  represent  elements  in  the  problem  space. 
This  representation  is  general  enough  that  the  programmer  is  not 
constrained  to  any  particular  type  of  problem.  We  refer  to  the 
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dements  in  the  problem  space  and  their  representations  in  the 
solution  space  as  "objects."  (Of  course,  you  will  also  need  other 
objects  that  don't  have  problem-space  analogs.)  The  idea  is  that  the 
program  is  allowed  to  adapt  itself  to  the  lingo  of  the  problem  by 
adding  new  typesof  objects,  so  when  you  read  the  code  describing 
the  solution,  you're  reading  words  that  also  express  the  problem. 
This  is  a more  flexible  and  powerful  language  abstraction  than 
what  we've  had  before.  Thus,  OOP  allowsyou  to  describe  the 
problem  in  terms  of  the  problem,  rather  than  in  terms  of  the 
computer  where  the  solution  will  run.  There's  still  a connection 
back  to  the  computer,  though.  Each  object  looks  quite  a bit  like  a 
little  computer;  it  hasa  state,  and  it  has  operations  that  you  can  ask 
it  to  perform.  However,  this  doesn't  seem  I ike  such  a bad  analogy 
to  objects  i n the  real  world;  they  all  have  character! sties  and 
behaviors. 

Some  language  designers  have  decided  that  object-oriented 
programming  by  itself  is  not  adequate  to  easily  solve  all 
programming  problems,  and  advocate  the  combi  nation  of  various 
approaches  into  multi  paradigm  programming  languages.^ 

Alan  Kay  summarized  five  basic  character! sties  of  Smalltalk,  the 
first  successful  object-oriented  language  and  one  of  the  languages 
upon  which  C-H- is  based.  These  character! sties  represent  a pure 
approach  to  object-oriented  programming: 

1.  Everything  is  an  objeetThinkof  an  object  as  a fancy 
variable;  it  stores  data,  but  you  can  "make  requests"  to  that 
object,  asking  itto  perform  operations  on  itself.  In  theory, 
you  can  take  any  conceptual  component  in  the  problem 
you'retrying  to  solve  (dogs,  buildings,  services,  etc.)  and 
represent  it  as  an  object  in  your  program. 

2.  A program  is  a bunch  of  objects  telling  each 
other  what  to  do  by  sending  message^o  make  a 


^ See  M ultiparadigm  Programming  in  Leda  by  Timothy  Budd  (Addison-Wesley  1995). 
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request  of  an  object,  you  "send  a message"  to  that  object. 

M ore  concretely,  you  can  think  of  a message  as  a request  to 
call  a function  that  belongs  to  a particular  object. 

3.  Each  object  has  its  own  memory  made  up  of 
other  objects  Put  another  way,  you  create  a new  kind  of 
object  by  making  a package  containing  existing  objects.  Thus, 
you  can  build  complexity  in  a program  while  hiding  it 
behind  the  simplicity  of  objects. 

4.  Every  object  has  a typeUsing  the  parlance,  each  object 
isan  in  stance  of  a class,  in  which  "class"  is  synonymous  with 
"type."  The  most  important  distinguishing  characteristic  of  a 
class  is  "What  messages  can  you  send  to  it?" 

5.  All  objects  of  a particular  type  can  receive  the 
same  messagesThis  is  actually  a loaded  statement,  as 
you  will  see  later.  Because  an  object  of  type  "circle"  is  also  an 
object  of  type  "shape,"  a circle  is  guaranteed  to  accept  shape 
messages.  Thi  s means  you  can  write  code  that  tal  ks  to  shapes 
and  automatically  handles  anything  that  fits  the  description 
of  a shape.  This  substitutability  is  one  of  the  most  powerful 
concepts  in  OOP. 

An  object  has  an  interface 

Aristotlewas  probably  the  first  to  begin  a careful  study  of  the 
concept  of  type,  he  spoke  of  "the  class  of  fishes  and  the  class  of 
birds."  The  idea  that  all  objects,  while  being  unique,  are  also  part  of 
a class  of  objects  that  have  characteristics  and  behaviors  in  common 
was  used  directly  in  the  first  object-oriented  language,  Simula-67, 
with  its  fundamental  keyword  classthat  introduces  a new  type  into 
a program. 
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Simula,  as  its  name  implies,  was  created  for  developing  simulations 
such  astheclassic  "bank  teller  problem2."  In  this,  you  have  a bunch 
of  tellers,  customers,  accounts,  transactions,  and  units  of  money  - a 
lot  of  "objects."  Objects  that  are  identical  except  for  their  state 
during  a program's  execution  are  grouped  together  into  "classes  of 
objects"  and  that's  where  the  keyword  classcamefrom.  Creating 
abstract  data  types  (classes)  is  a fundamental  concept  in  object- 
oriented  programming.  Abstract  datatypes  work  almost  exactly 
I i ke  bu  i It-i  n types:  Y ou  can  create  vari  abl  es  of  a type  (cal  I ed  objects 
or  instances  in  object-oriented  parlance)  and  manipulate  those 
variables  (called  sending  messages  or  requests-,  you  send  a message 
and  the  object  figures  out  what  to  do  with  it).  The  members 
(elements)  of  each  class  share  some  commonal  ity:  every  account 
has  a balance,  every  tel  ler  can  accept  a deposit,  etc.  At  the  same 
time,  each  member  has  its  own  state,  each  account  has  a different 
balance,  each  teller  has  a name.  Thus,  the  tellers,  customers, 
accounts,  transactions,  etc,  can  each  be  represented  with  a unique 
entity  i n the  computer  program.  This  entity  is  the  object,  and  each 
object  belongs  to  a particular  cl  ass  that  defines  its  characteristics 
and  behaviors. 

So,  although  what  we  really  do  in  object-oriented  programming  is 
create  new  datatypes,  virtually  all  object-oriented  programming 
languages  use  the  "class"  keyword.  When  you  see  the  word  "type" 
think  "class"  and  viceversa^. 

Since  a class  descri  bes  a set  of  objects  that  have  identical 
characteristics  (data  elements)  and  behaviors  (functionality),  a class 
is  really  a data  type  because  a floating  point  number,  for  example, 
also  has  a set  of  characteristics  and  behaviors.  The  difference  is  that 
a programmer  defines  a class  to  fit  a problem  rather  than  being 
forced  to  use  an  existing  data  type  that  was  designed  to  represent  a 


2 You  can  find  an  interesting  implementation  of  this  problem  in  Volume  2 of  this 
book,  available  at  www.BruceEckel.com. 

2 Some  people  make  a distinction,  stating  that  type  determines  the  interface  while 
cl  ass  i s a parti  cu  I ar  i mpl  ementatl  on  of  that  i nterface. 
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unit  of  storage  in  a machine.  You  extend  the  programming 
language  by  adding  new  datatypes  specificto  your  needs.  The 
programming  system  welcomes  the  new  cl  asses  and  gives  them  all 
the  care  and  type-check!  ng  that  it  gives  to  bui  It-i  n types. 

The  object-oriented  approach  is  not  limited  to  building  simulations. 
Whether  or  not  you  agree  that  any  program  isa  simulation  of  the 
system  you're  designing,  the  use  of  OOP  techniques  can  easily 
red uce  a I arge  set  of  probi ems  to  a si  mpl e sol uti on. 

Once  a class  is  estabi  ished,  you  can  make  as  many  objects  of  that 
class  as  you  like,  and  then  man!  pulatethose  objects  as  if  they  are 
the  elements  that  exist  in  the  problem  you  are  trying  to  solve. 
Indeed,  oneof  the  challenges  of  object-oriented  programming  isto 
create  a one-to-one  mapping  between  the  elements  in  the  problem 
space  and  objects  in  the  sol  uti  on  space. 

But  how  do  you  get  an  object  to  do  useful  work  for  you?  There 
must  bea  way  to  make  a request  of  the  object  so  that  it  will  do 
something,  such  as  complete  a transaction,  draw  something  on  the 
screen  or  turn  on  a switch.  And  each  object  can  satisfy  only  certain 
requests.  The  requests  you  can  make  of  an  object  are  defined  by  its 
interface,  and  thetype  is  what  determines  the  interface.  A simple 
example  might  bea  representation  of  a light  bulb: 


Light 


on() 

offO 

brighten( ) 
dimO 


Light  It; 

It . on  ( ) ; 

The  interface  establishes  what  requests  you  can  make  for  a 
particular  object.  However,  there  must  be  code  somewhere  to 
satisfy  that  request.  This,  along  with  the  hidden  data,  comprises  the 


Type  Name 
I nterface 
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implementation.  From  a procedural  programming  standpoint,  it's 
not  that  complicated.  A type  has  a function  associated  with  each 
possible  request,  and  when  you  make  a particular  request  to  an 
object,  that  function  is  called.  This  process  is  usually  summarized 
by  saying  that  you  "send  a message"  (make a request)  to  an  object, 
and  the  object  figures  out  what  to  do  with  that  message  (it  executes 
code). 

Here,  the  name  of  the  type/'  class  is  Light  the  name  of  this 
particular  Lightobject  is  It  and  the  requests  that  you  can  make  of  a 
Lightobjectaretoturn  it  on,  turn  it  off,  make  it  brighter  or  make  it 
dimmer.  You  create  a Lightobject  by  declaring  a name  (It)  for  that 
object.  T 0 send  a message  to  the  object,  you  state  the  name  of  the 
object  and  connect  it  to  the  message  request  with  a period  (dot). 
From  the  standpoint  of  the  user  of  a pre-defi  ned  class,  that's  pretty 
much  all  there  is  to  programming  with  objects. 

Thediagram  shown  abovefollowstheformat  of  the  dn/f/ed 
M odeling  Language  {UML).  Each  class  is  represented  by  a box,  with 
the  type  name  in  the  top  portion  of  the  box,  any  data  members  that 
you  care  to  describe  in  the  middle  portion  of  the  box,  and  the 
member  functions  {thefunctionsthat  belong  to  this  object,  which 
receive  any  messages  you  send  to  that  object)  in  the  bottom  portion 
of  the  box.  Often,  only  the  name  of  the  class  and  the  public  member 
functions  are  shown  in  UM  L design  diagrams,  and  so  the  middle 
portion  isnot  shown.  If  you 're  interested  only  in  the  cl  ass  name, 
then  the  bottom  portion  doesn't  need  to  be  shown,  either. 


The  hidden  implementation 

It  is  helpful  to  break  up  the  playing  field  into  class  creators  (those 
who  create  new  datatypes)  and  client  programmers'^  (the  class 
consu  mers  w ho  use  the  data  types  i n thei  r appi  i cati  ons).  The  goal 
of  the  cl  i ent  programmer  i s to  col  I ect  a tool  box  f u 1 1 of  cl  asses  to  use 


^ I'm  indebted  to  my  friend  Scott  Meyers  for  this  term. 
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for  rapid  application  development.  The  goal  of  the  cl  ass  creator  is 
to  bu  i I d a cl  ass  that  exposes  only  what's  necessary  to  the  cl  lent 
programmer  and  keeps  everything  else  hidden.  Why?  Because  if 
it's  hidden,  the  cl  lent  programmer  can't  use  it,  which  means  that 
the  cl  ass  creator  can  change  the  hidden  portion  atwill  without 
worrying  about  the  i mpact  to  anyone  else.  The  hidden  portion 
usually  represents  the  tender  insides  of  an  object  that  could  easily 
be  corrupted  by  a careless  or  uninformed  client  programmer,  so 
hiding  the  implementation  reduces  program  bugs.  The  concept  of 
implementation  hiding  cannot  be  overemphasized. 

In  any  relationship  it's  important  to  have  boundaries  that  are 
respected  by  all  parties  involved.  When  you  create  a library,  you 
establish  a relationship  with  the  client  programmer,  who  isalso  a 
programmer,  but  one  who  is  putting  together  an  application  by 
using  your  library,  possibly  to  build  a bigger  library. 

If  all  the  members  of  a class  are  aval  I able  to  everyone,  then  the 
client  programmer  can  do  anything  with  that  class  and  there's  no 
way  to  enforce  rules.  Even  though  you  might  really  prefer  that  the 
client  programmer  notdirectly  manipulate  some  of  the  members  of 
your  class,  without  access  control  there's  no  way  to  prevent  it. 
Everything's  naked  to  the  world. 

So  the  f i rst  reason  for  access  control  i s to  keep  cl  i ent  programmers' 
hands  off  portions  they  shouldn't  touch  - parts  that  are  necessary 
for  the  internal  machinations  of  the  data  type  but  not  part  of  the 
interface  that  users  need  in  order  to  solvetheir  particular  problems. 
This  is  actually  a service  to  users  because  they  can  easily  see  what's 
important  to  them  and  what  they  can  ignore. 

The  second  reason  for  access  control  is  to  allow  the  library  designer 
to  change  the  i nternal  worki  ngs  of  the  cl  ass  w ithout  worry!  ng 
about  how  it  will  affect  the  cl  lent  programmer.  For  example,  you 
might  implement  a particular  class  in  a simple  fashion  to  ease 
development,  and  then  later  discover  that  you  need  to  rewrite  it  in 
order  to  makeit  run  faster.  If  the  interface  and  implementation  are 


1:  I ntroduction  to  Objects 


31 


clearly  separated  and  protected,  you  can  accomplish  this  easily  and 
require  only  a relink  by  the  user. 


C++ uses  three  exp  licit  keywords  to  set  the  boundaries  in  a class: 
public  private  and  protected  Their  use  and  meaning  are  quite 
straightforward.  The^  access  specifiers  determine  who  can  use  the 
definitions  that  follow,  public  means  the  foil  owing  definitions  are 
availableto  everyone.  Theprivatekeyword,  on  the  other  hand, 
means  that  no  one  can  access  those  defi  nitions  except  you,  the 
creator  of  the  type,  inside  member  functions  of  that  type,  private!  s 
a brick  wall  between  you  and  the  client  programmer.  If  someone 
tries  to  access  a privatemember,  they'll  get  a compile-time  error, 
protectedacts  just  I ike  private  with  the  except! on  that  an 
inheriting  class  has  access  to  protected  members,  but  not  private 
members.  Inheritance  will  be  introduced  shortly. 


Reusing  the  implementation 

Once  a class  has  been  created  and  tested,  it  should  (ideally) 
represent  a useful  unit  of  code.  It  turns  out  that  this  reusability  is 
not  nearly  so  easy  to  achieve  as  many  would  hope;  it  takes 
experience  and  insight  to  produceagood  design.  But  once  you 
have  such  a design,  it  begs  to  be  reused.  Code  reuse  is  one  of  the 
greatest  advantages  that  object-oriented  programming  languages 
provide. 

The  simplest  way  to  reuse  a class  is  to  just  use  an  object  of  that  class 
directly,  but  you  can  also  place  an  objectof  that  cl  ass  inside  a new 
class.  We  call  this  "creating  a member  object."  Your  new  class  can 
be  made  up  of  any  number  and  type  of  other  objects,  in  any 
combination  that  you  need  to  achievethefunctionality  desired  in 
your  new  class.  Because  you  are  composing  a new  cl  ass  from 
existing  classes,  this  concept  is  called  composition  (or  more 
generally,  aggregation).  Composition  is  often  referred  to  asa  "has-a" 
relationship,  as  in  "a  car  has  an  engine." 
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(TheaboveUML  diagram  indicates  composition  with  the  filled 
diamond,  which  states  there  is  one  car.  I will  typically  useasimpler 
form:  just  a line,  without  the  diamond,  to  indicate  an  association.^) 

Composition  comeswith  agreatdeal  of  flexibility.  The  member 
objects  of  your  new  class  are  usually  private,  making  them 
i naccessi  bl  e to  the  cl  i ent  programmers  w ho  are  usi  ng  the  cl  ass.  Thi  s 
allowsyou  to  change  those  members  without  disturbing  existing 
client  code.  You  can  also  change  the  member  objects  at  runtime,  to 
dynamically  change  the  behavior  of  your  program.  Inheritance, 
which  is  described  next,  doesnothavethisflexibility  sincethe 
compiler  must  place  compile-time  restrictions  on  cl  asses  created 
with  inheritance. 

Because  inheritance  is  so  important  in  object-oriented 
programming  it  is  often  highly  emphasized,  and  the  new 
programmer  can  get  the  idea  that  inheritance  should  be  used 
everywhere.  This  can  result  in  awkward  and  overly-complicated 
designs.  Instead,  you  should  first  look  to  composition  when 
creating  new  classes,  since  it  is  simpler  and  more  flexible.  If  you 
take  this  approach,  your  designs  will  stay  cleaner.  Once  you've  had 
some  experience,  it  will  be  reasonably  obvious  when  you  need 
inheritance. 


5 This  is  usually  enough  detail  for  most  diagrams,  and  you  don't  need  to  get  specific 
about  whether  you're  using  aggregation  or  composition. 
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I nheritance: 
reusing  the  interface 

By  itself,  the  idea  of  an  object  is  a convenient  tool.  It  allows  you  to 
package  data  and  functional  ity  together  by  concept,  so  you  can 
represent  an  appropriate  problenn-space  idea  rather  than  being 
forced  to  usethe  idioms  of  the  underlying  machine.  These  concepts 
are  expressed  as  fundamental  units  in  the  programming  language 
by  using  the  cl  ass  keyword. 

It  seems  a pity,  however,  to  goto  all  the  trouble  to  create  a cl  ass 
and  then  deforced  to  create  a brand  new  one  that  might  have 
similar  functionality.  It'snicer  if  wecan  take  the  existing  class, 
clone  it,  and  then  make  additions  and  modifications  to  the  cl  one. 
This  is  effectively  what  you  get  with  inheritance,  with  the  exception 
that  if  the  original  cl  ass  (cal  led  the  base  or  super  or  parent  cl  ass)  is 
changed,  the  modified  "clone”  (called  thederived  or  inherited  or  sub 
or  chi  id  class)  also  reflects  those  changes. 


(The  arrow  in  the  above  UM  L diagram  points  from  the  derived 
class  to  the  base  class.  As  you  will  see,  there  can  be  more  than  one 
derived  class.) 

A type  does  more  than  describe  the  constraints  on  a set  of  objects;  it 
also  has  a relationship  with  other  types.  Two  types  can  have 
characteristics  and  behaviors  in  common,  but  one  type  may  contain 
more  characteristics  than  another  and  may  also  handle  more 
messages  (or  handlethem  differently).  I nheritance  expresses  this 
si  mi  larity  between  types  usi  ng  the  concept  of  base  types  and 
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derived  types.  A base  ty pe  contai  ns  al  I of  the  characteristics  and 
behaviors  that  are  shared  among  the  types  derived  from  it.  You 
create  a base  type  to  represent  the  core  of  your  ideas  about  some 
objects  in  your  system.  From  the  base  type,  you  derive  other  types 
to  express  the  d ifferent  ways  that  this  core  can  be  real  i zed . 

For  example,  a trash-recycl  i ng  machinesorts  pieces  of  trash.  The 
base  type  is  "trash,"  and  each  piece  of  trash  hasa  weight,  a value, 
and  so  on,  and  can  be  shredded,  melted,  or  decomposed.  From  this, 
more  specific  types  of  trash  are  derived  that  may  have  additional 
characteristics  (a  bottle  has  a color)  or  behaviors  (an  aluminum  can 
may  be  crushed,  a steel  can  is  magnetic).  In  addition,  some 
behaviors  may  bedifferent  (thevalue  of  paper  depends  on  its  type 
and  condition).  Using  inheritance,  you  can  build  a type  hierarchy 
that  expresses  the  problem  you're  trying  to  solve  in  terms  of  its 
types. 

A second  example  is  the  classic  "shape"  example,  perhaps  used  in  a 
computer-aided  design  system  or  gamesimulation.  The  base  type 
is  "shape,"  and  each  shape  has  a size,  a color,  a position,  and  so  on. 
Each  shape  can  be  drawn,  erased,  moved,  colored,  etc.  From  this, 
specific  types  of  shapes  are  derived  (inherited):  circle,  square, 
triangle,  and  so  on,  each  of  which  may  have  additional 
character!  sties  and  behaviors.  Certain  shapes  can  be  flipped,  for 
example.  Some  behaviors  may  be  different,  such  as  when  you  want 
to  cal  cu  I ate  the  area  of  a shape.  The  type  hierarchy  embodies  both 
the  similarities  and  differences  between  the  shapes. 
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Casting  the  solution  in  the  same  terms  as  the  problem  is 
tremendously  beneficial  because  you  don't  need  a lot  of 
intermediate  models  to  get  from  a description  of  the  problem  to  a 
description  of  the  solution.  With  objects,  the  type  hierarchy  isthe 
primary  model,  so  you  go  directly  from  the  description  of  the 
system  in  the  real  world  to  the  description  of  the  system  in  code. 
Indeed,  one  of  the  difficulties  people  have  with  object-oriented 
desi  gn  i s that  it's  too  si  mpl  e to  get  from  the  begi  nni  ng  to  the  end . A 
mind  trained  to  look  for  complex  solutions  is  often  stumped  by  this 
simplicity  atfi  rst. 

When  you  inherit  from  an  existing  type,  you  create  a new  type. 

This  new  type  contai  ns  not  only  al  I the  members  of  the  exist!  ng 
type(although  the privateones are  hidden  away  and  inaccessible), 
but  more  importantly  it  dupl  icates  the  interface  of  the  base  class. 
That  i s,  al  I the  messages  you  can  send  to  objects  of  the  base  cl  ass 
you  can  also  send  to  objects  of  the  derived  class.  Si  nee  we  know  the 
type  of  a class  by  the  messages  we  can  send  to  it,  this  means  that 
the  derived  class  is  the  same  type  as  the  base  class.  I n the  previous 
example,  "a  circle  is  a shape."  This  type  equivalence  via  inheritance 
is  one  of  the  fundamental  gateways  in  understanding  the  meaning 
of  object-oriented  programming. 
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Since  both  the  base  class  and  derived  class  have  the  same  interface, 
there  must  be  some  implementation  to  go  along  with  that  i nterface. 
That  is,  there  must  be  some  codeto  execute  when  an  object  receives 
a particular  message.  If  you  simply  inherit  a class  and  don't  do 
anyth!  ng  el  se,  the  methods  from  the  base-cl  ass  i nterface  come  ri  ght 
along  into  the  derived  class.  That  means  objects  of  the  derived  class 
have  not  only  the  same  type,  they  also  have  the  same  behavior, 
which  isn't  particularly  interesting. 

You  havetwo  ways  to  different!  ate  your  new  derived  class  from 
the  ori  gi  nal  base  cl  ass.  The  f i rst  i s qu  ite  strai  ghtforward : Y ou 
simply  add  brand  new  functions  to  the  derived  class.  These  new 
functions  are  not  part  of  the  base  class  interface.  This  means  that 
the  base  class  simply  didn't  do  as  much  as  you  wanted  it  to,  so  you 
added  more  functions.  This  simple  and  primitive  use  for 
inheritance  is,  at  times,  the  perfect  solution  to  your  problem. 
However,  you  should  look  closely  for  the  possibility  that  your  base 
cl  ass  mi  ght  al  so  need  these  add  iti  onal  fu  ncti  ons.  Thi  s process  of 
discovery  and  iteration  of  your  design  happens  regularly  in  object- 
oriented  programming. 
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Although  inheritancemay  sometimes  imply  that  you  are  going  to 
add  new  functionsto  the  interface,  that's  not  necessarily  true.  The 
second  and  more  i mportant  way  to  different  ate  your  new  class  is 
to  c/iange the  behavior  of  an  existing  base-classfunction.Thisis 
referred  to  as  overriding  that  function. 


To  override  a function,  you  simply  createa  new  definition  for  the 
function  in  thederived  class.  You're  saying,  "I'm  using  the  same 
interface  function  here,  but  I want  it  to  do  something  different  for 
my  new  type." 

Is-a  vs.  is-like-a  relationships 

There's  a certain  debate  that  can  occur  about  inheritance:  Should 
inheritance  override  on/y  base-class  functions  (and  not  add  new 
member  functions  that  aren't  in  the  base  class)?  This  would  mean 
that  the  deri  ved  type  i s exactiy  the  same  type  as  the  base  cl  ass  si  nee 
it  has  exactly  the  same  i nterface.  As  a result,  you  can  exactly 
substitute  an  object  of  the  derived  class  for  an  object  of  the  base 
class.  This  can  bethought  of  as  pure  substitution,  and  it's  often 
referred  to  as  the  substitution  principie.  In  a sense,  this  is  the  ideal 
way  to  treat  inheritance.  We  often  refer  to  the  relationship  between 
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the  base  class  and  derived  classes  in  this  case  as  an  /s-a  relationship, 
because  you  can  say  "a  circle /s  a shape."  A test  for  inheritance  is  to 
determine  whether  you  can  state  theis-a  relationship  about  the 
classes  and  have  it  make  sense. 

There  are  times  when  you  must  add  new  interface  elements  to  a 
derived  type,  thus  extending  the  interface  and  creating  a new  type. 
The  new  type  can  still  be  substituted  for  the  base  type,  but  the 
substitution  isn't  perfect  because  your  new  functions  are  not 
accessiblefrom  the  basetype.  This  can  be  described  as  an  is-like-a 
rel  ati  onshi  p;  the  new  type  has  the  i nterface  of  the  ol d type  but  it 
also  contains  other  functions,  so  you  can't  really  say  it's  exactly  the 
same.  For  example,  consider  an  air  conditioner.  Suppose  your 
houseiswired  with  all  the  controls  for  cooling;  that  is,  it  has  an 
interface  that  allows  you  to  control  cooling.  Imagine  that  the  air 
conditioner  breaks  down  and  you  replace  it  with  a heat  pump, 
which  can  both  heat  and  cool.  The  heat  pump  is-like-an  air 
conditioner,  but  it  can  do  more.  Because  the  control  system  of  your 
house  is  designed  only  to  control  cooling,  it  is  restricted  to 
communication  with  the  cooling  part  of  the  new  object.  The 
i nterface  of  the  new  object  has  been  extended,  and  the  existing 
system  doesn't  know  about  anything  except  the  original  interface. 


Thermostat 

Controls 

Cooling  Systen 

lowerTemperature( ) 

coolO 

5 




Air  Conditione 



Heat  Pump 

coolO 

coolO 

heat( ) 

Of  course,  once  you  see  this  design  it  becomes  clear  that  the  base 
class  "cooling  system"  is  not  general  enough,  and  should  be 
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renamed  to  "temperature  control  system"  so  that  it  can  also  include 
heating  - at  which  point  the  substitution  principlewill  work. 
However,  the  diagram  above  is  an  exampleof  what  can  happen  in 
design  and  in  the  real  world. 

When  you  see  the  substitution  principle  it's  easy  to  feel  I ike  this 
approach  (pure  substitution)  istheonly  way  to  do  things,  and  in 
fact  it /s  nice  if  your  design  works  out  that  way.  But  you'll  find  that 
there  are  times  when  it's  equally  clear  that  you  must  add  new 
functions  to  the  interface  of  a derived  class.  With  inspection  both 
cases  should  be  reasonably  obvious. 


Interchangeable  objects 
with  polymorphism 

When  dealing  with  type  hierarchies,  you  often  want  to  treat  an 
object  not  as  the  specific  type  that  it  is  but  instead  as  its  base  type. 
Thisallowsyou  to  write  code  that  doesn't  depend  on  specific  types. 
I n the  shape  exampi  e,  fu  ncti  ons  mani  pu  I ate  generi  c shapes  w i thout 
respect  to  whether  they're  circles,  squares,  triangles,  and  soon.  All 
shapes  can  be  drawn,  erased,  and  moved,  so  these  functions  simply 
send  a message  to  a shape  object;  they  don't  worry  about  how  the 
object  copes  with  the  message. 

Such  code  is  unaffected  by  the  addition  of  new  types,  and  adding 
new  types  is  the  most  common  way  to  extend  an  object-oriented 
program  to  handle  new  situations.  For  example,  you  can  derive  a 
new  subtype  of  shape  cal  led  pentagon  without  modifying  the 
functions  that  deal  only  with  generic  shapes.  This  abi  I ity  to  extend 
a program  easily  by  deriving  new  subtypes  is  important  because  it 
greatly  i mproves  desi  gns  whi  le  reduci  ng  the  cost  of  software 
maintenance. 

There's  a problem,  however,  with  attempting  to  treat  derived-type 
objects  as  thei  r generi  c base  types  (ci  rcl  es  as  shapes,  bi  cycl  es  as 
vehicles,  cormorants  as  birds,  etc).  If  a function  is  going  to  tell  a 
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generic  shape  to  draw  itself,  or  a gen  eric  vehicle  to  steer,  ora 
generic  bird  to  move,  the  compiler  cannot  know  at  compile-time 
precisely  what  piece  of  code  will  be  executed.  That's  the  whole 
poi  nt  - when  the  message  is  sent,  the  programmer  doesn't  want  to 
know  what  piece  of  code  will  be  executed;  thedraw  function  can  be 
applied  equally  to  a circle,  a square,  or  a triangle,  and  the  object 
will  executethe  proper  code  depending  on  its  specific  type.  If  you 
don't  haveto  know  what  piece  of  codewill  be  executed,  then  when 
you  add  a new  subtype,  the  code  it  executes  can  be  different 
without  requ i ri  ng  changes  to  the  fu net!  on  cal  I . Therefore,  the 
compiler  cannot  know  precisely  what  piece  of  code  is  executed,  so 
what  does  it  do?  For  example,  in  the  following  diagram  the 
BirdControlleiobjectjust  works  with  generic  Bird  objects,  and 
does  not  know  what  exact  type  they  are.  This  is  convenient  from 
BirdControlleis  perspective,  because  it  doesn't  haveto  write 
special  codeto  determine  the  exact  type  of  Bird  it's  working  with, 
or  that  Bird's  behavior.  So  how  does  it  happen  that,  when  move( ) 
i s cal  I ed  w hi  I e i gnori ng  the  specif i c type  of  Bird,  the  ri ght  behavi or 
will  occur  (a  Goose  runs,  flies,  or  swims,  and  a Penguin  runs  or 
swims)? 


BirdController 


reLocate( ) 


What  happens 
when  moveO  is 
called? 


Bird 


moveO 


Goose 

Penguin 

move( ) 

moveO 

The  answer  isthe  primary  twist  in  object-oriented  programming: 
The  compiler  cannot  makeafunction  call  in  the  traditional  sense. 
The  function  call  generated  by  a non-OOP  compiler  causes  what  is 
called  early  binding,  a term  you  may  not  have  heard  before  because 
you've  never  thought  about  it  any  other  way.  It  means  the  compi  ler 
generates  a call  to  a specific  function  name,  and  the  linker  resolves 
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thiscall  to  the  absolute  address  of  the  code  to  be  executed.  In  OOP, 
the  program  cannot  determine  the  address  of  the  code  unti  I 
runti  me,  so  some  other  scheme  is  necessary  when  a message  is  sent 
to  a generic  object. 

To  solve  the  problem,  object-oriented  languages  use  the  concept  of 
late  binding.  When  you  send  a message  to  an  object,  the  code  being 
called  isn't  determined  until  runtime.  The  compiler  does  ensure 
that  the  function  exists  and  performs  type  checki  ng  on  the 
arguments  and  return  value  (a  language  in  which  this  isn't  true  is 
called  weakly  typed),  but  it  doesn't  know  the  exact  code  to  execute. 

To  perform  late  binding,  the  C-H- compiler  inserts  a special  bit  of 
codein  lieu  of  the  absolute  call. Thiscode  calculates  the  address  of 
the  function  body,  using  information  stored  in  the  object  (this 
process  is  covered  in  great  detail  in  Chapter  15).  Thus,  each  object 
can  behave  differently  accordi  ng  to  the  contents  of  that  special  bit 
of  code.  When  you  send  a message  to  an  object,  the  object  actually 
does  figure  out  what  to  do  with  that  message. 

Y ou  state  that  you  want  a f u ncti  on  to  have  the  f I exi  bi  I i ty  of  I ate- 
binding  properties  using  the  keyword  virtual.  You  don't  need  to 
understand  the  mechanics  of  virtual  to  use  it,  but  without  it  you 
can't  do  object-oriented  programming  in  C-H-.  In  C-H-,  you  must 
remember  to  add  the  virtual  keyword  because,  by  default,  member 
functions  are  not  dynamically  bound.  Virtual  functions  allow  you 
to  express  the  differences  in  behavior  of  classes  in  the  same  family. 
Those  differences  are  what  cause  polymorphic  behavior. 

Considertheshapeexample.  The  family  of  cl  asses  (all  based  on  the 
same  uniform  interface)  was  diagrammed  earlier  in  the  chapter.  To 
demonstrate  polymorphism,  we  want  to  write  a single  piece  of 
code  that  i gnores  the  specif  i c detai  I s of  type  and  tal  ks  onl  y to  the 
base  class.  That  code  \s  decoupled  from  type-specific  information, 
and  thus  is  simpler  to  write  and  easier  to  understand.  And,  if  a new 
type  - a Hexagon  for  example  - is  added  through  inheritance,  the 


42 


Thinking  in  C-I--I- 


www.BruceEckel.com 


code  you  write  will  work  just  as  well  for  the  new  typeof  Shapeas 
it  did  on  the  existing  types.  Thus,  the  program  is  odensible. 

If  you  write  a function  in  C++(asyou  will  soon  learn  how  to  do): 

void  doStuff (Shapes  s)  { 
s . erase  ( ) ; 

//  ... 

s . draw  ( ) ; 

} 

This  function  speaks  to  any  Shapa  so  it  is  independent  of  the 
specifictypeof  object  that  it's  drawing  and  erasing  (the'&'  means 
"Take  the  address  of  the  object  that's  passed  to  doStuff( )"  but  it's 
not  important  that  you  understand  thedetailsof  that  right  now).  If 
in  some  other  part  of  the  program  weusethedoStuff(  Ku  notion: 

Circle  c; 

Triangle  t; 

Line  1; 
doStuff (c) ; 
doStuf f (t ) ; 
doStuff  (1) ; 

ThecallstodoStuff(  )automatically  work  right,  regardless  of  the 
exact  type  of  the  object. 

This  is  actually  a pretty  amazing  trick.  Consider  the  line: 

doStuff (c) ; 

What's  happening  here  isthat  a Circleis  being  passed  into  a 
function  that's  expect!  ng  a Shape  Si  nee  a C ircle/s  a Shapeit  can  be 
treated  as  one  by  doStuff  ( )That  is,  any  message  that  doStuff  ( ) 
can  send  to  a Shape  a C irclecan  accept.  So  it  is  a completely  safe 
and  logical  thing  to  do. 

We  cal  I this  process  of  treating  a derived  type  as  though  it  were  its 
base  type  upcasting.  The  name  cast  is  used  in  the  sense  of  casting 
into  a mold  and  theupcomesfromtheway  theinheritancediagram 
is  typically  arranged,  with  the  base  type  at  the  top  and  the  derived 
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classes  fanning  out  downward.  Thus,  casting  to  a base  type  is 
moving  up  the  inheritance  diagram:  "upcasting." 


An  object-oriented  program  contains  some  upcasting  somewhere, 
because  that's  how  you  decouple  yourself  from  knowing  about  the 
exact  type  you're  working  with.  Look  atthecodein  doStuff( ) 

s . erase  ( ) ; 

//  . . . 

s . draw  ( ) ; 

N ot i ce th at i t d oesn 'tsay"lfyou'reaCirclcjdothis,  ifyou'rea 
Square  do  that,  etc."  If  you  write  that  kind  of  code,  which  checks 
for  all  the  possible  types  that  a Shapecan  actually  be,  it's  messy 
and  you  need  to  changeit  every  time  you  add  a new  kind  of  Shape 
H ere,  you  just  say  "You're  a shape,  I know  you  can  erase(  )and 
draw(  )yourself,  do  it,  and  take  care  of  the  details  correctly." 

What's  impressive  about  the  code  in  doStuff(  )isthat,  somehow, 
the  right  thing  happens.  Calling  draw(  )forCirclecauses  different 
code  to  be  executed  than  when  calling  draw(  )for  a Squareor  a 
Line  but  when  thedraw(  )messageissentto  an  anonymous 
Shape  the  correct  behavior  occurs  based  on  the  actual  type  of  the 
Shape  This  is  amazing  because,  as  mentioned  earlier,  when  the 
C-H- compiler  i s compiling  the  code  for  doStuff( ) it  cannot  know 
exactly  what  types  it  is  dealing  with.  So  ordinarily,  you'd  expect  it 
to  end  up  calling  the  version  of  erase(  )and  draw(  )for  Shape  and 
not  for  the  specific  Circle  Square  or  Line  And  yet  the  right  thing 
happens  because  of  polymorphism.  The  compiler  and  runtime 
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system  handlethe details;  all  you  need  to  know  isthat  it  happens 
and  more  importantly  how  to  design  with  it.  If  a member  function 
isvirtual  then  when  you  send  a message  to  an  object,  theobject 
will  do  the  right  thing,  even  when  upcasting  is  involved. 


Creating  and  destroying  objects 

Technically,  the  domain  of  OOP  is  abstract  data  typing,  inheritance, 
and  polymorphism,  but  other  issues  can  be  at  least  as  important. 
This  section  gives  an  overview  of  these  issues. 

Especially  important  is  the  way  objects  are  created  and  destroyed. 
Where  is  the  data  for  an  object  and  how  isthe  lifetime  of  that  object 
controlled?  Different  programming  languages  use  different 
philosophies  here.  C++takes  the  approach  that  control  of  efficiency 
isthe  most  i mportant  issue,  so  it  gives  the  programmer  a choice. 

For  maximum  runtime  speed,  the  storage  and  lifetime  can  be 
determined  whilethe  program  is  being  written,  by  placing  the 
objects  on  the  stack  or  in  static  storage.  The  stack  is  an  area  in 
memory  that  is  used  directly  by  the  microprocessor  to  store  data 
during  program  execution.  Variables  on  the  stack  are  sometimes 
called  automat/corscopecfvariables. Thestaticstoragearea  issimply 
a fixed  patch  of  memory  that  is  allocated  before  the  program  begins 
to  run.  Using  thestack  or  static  storage  area  places  a priority  on  the 
speed  of  storage  allocation  and  release,  which  can  be  valuable  in 
some  situations.  However,  you  sacrifice  flexibility  because  you 
must  know  the  exact  quantity,  I ifeti  me,  and  type  of  objects  while 
you'rewriting  the  program.  If  you  aretryingtosolvea  more 
general  problem,  such  as  computer-aided  design,  warehouse 
management,  or  air-traffic  control,  this  is  too  restrictive. 

The  second  approach  is  to  create  objects  dynamically  in  a pool  of 
memory  called  the /leap.  In  this  approach  you  don't  know  until 
runtime  how  many  objects  you  need,  what  their  lifetime  is,  or  what 
thei  r exact  ty  pe  i s.  Those  deci  si  ons  are  mad e at  the  spu  r of  the 
moment  whilethe  program  is  running.  If  you  need  a new  object, 
you  si  mply  make  it  on  the  heap  when  you  need  it,  usi  ng  the  new 
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keyword.  When  you  Ye  finished  with  the  storage,  you  must  release 
it  using  the deletekeyword. 

Because  the  storage  is  managed  dynamically  at  runtime,  the 
amou  nt  of  ti  me  requ  i red  to  al  I ocate  storage  on  the  heap  i s 
significantly  longer  than  the  time  to  create  storage  on  the  stack. 
(Creating  storage  on  the  stack  is  often  a single  microprocessor 
instruction  to  move  the  stack  pointer  down,  and  another  to  move  it 
back  up.)  The  dynamic  approach  makes  the  generally  logical 
assumption  that  objects  tend  to  be  compi  icated,  so  the  extra 
overhead  of  finding  storage  and  releasing  that  storage  will  not  have 
an  i mportant  i mpact  on  the  creation  of  an  object.  In  addition,  the 
greater  flexibility  isessential  to  solve  general  programming 
problems. 

There's  another  issue,  however,  and  that's  the  lifetime  of  an  object. 

If  you  create  an  object  on  the  stack  or  i n static  storage,  the  compi  I er 
determines  how  long  the  object  lasts  and  can  automatically  destroy 
it.  However,  if  you  create  it  on  the  heap,  the  compiler  has  no 
knowledge  of  its  lifetime.  In  C++,  the  programmer  must  determine 
programmatically  when  to  destroy  the  object,  and  then  perform  the 
destruction  using  the  deletekeyword.  As  an  alternative,  the 
environment  can  provide  a feature  called  a garbage  col  lector  that 
automatically  discovers  when  an  object  is  no  longer  in  use  and 
destroys  it.  Of  course,  writing  programs  using  a garbage  col  lector  is 
much  more  convenient,  but  it  requ  ires  that  all  applications  must  be 
abl  e to  tol  erate  the  exi  stence  of  the  garbage  col  I ector  and  the 
overhead  for  garbage  col  I ecti  on.  Thi  s does  not  meet  the  desi  gn 
requirements  of  theC++language  and  so  itwasnot  included, 
although  third-party  garbage  col  lectors  exist  for  C-H-. 


Exception  handling: 
dealing  with  errors 

Ever  si  nee  the  beginning  of  programming  languages,  error 
handling  has  been  oneof  the  most  difficult  issues.  Becauseit'sso 
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hard  to  design  a good  error-handling  schenne,  many  languages 
simply  ignore  the  issue,  passing  the  problem  on  to  library  designers 
who  come  up  with  halfway  measures  that  can  work  in  many 
situations  but  can  easily  be  circumvented,  generally  by  just 
ignoring  them.  A major  problem  with  most  error-hand  ling  schemes 
isthatthey  rely  on  programmer  vigilance  in  following  an  agreed- 
upon  convention  that  is  not  enforced  by  the  language.  If 
programmers  are  not  vigilant,  which  often  occurs  when  they  are  in 
a hurry,  these  schemes  can  easily  beforgotten. 

Exception  handling  wires  error  handling  directly  into  the 
programming  language  and  someti  mes  even  the  operating  system. 
An  exception  is  an  object  that  is  "thrown"  from  the  site  of  the  error 
and  can  be  "caught"  by  an  appropriate  exception  handler  designed  to 
handle  that  particular  type  of  error.  It's  as  if  exception  handling  is  a 
different,  parallel  path  of  execution  that  can  betaken  when  things 
go  wrong.  And  because  it  uses  a separate  execution  path,  it  doesn't 
need  to  interfere  with  your  normally-executing  code.  This  makes 
that  code  simpler  to  write  si  nee  you  aren't  constantly  forced  to 
check  for  errors.  In  addition,  a thrown  exception  is  uni  ike  an  error 
value  that's  returned  from  a function  or  a flag  that's  set  by  a 
function  in  order  to  indicate  an  error  condition  - these  can  be 
ignored.  An  exception  cannot  be  ignored  so  it's  guaranteed  to  be 
dealt  with  at  some  point.  Finally,  exceptions  providea  way  to 
recover  reliably  from  a bad  situation.  Instead  of  just  exiting  the 
program,  you  are  often  able  to  set  things  right  and  restore  the 
execution  of  a program,  which  produces  much  more  robust 
systems. 

It's  worth  noting  that  exception  handling  isn't  an  object-oriented 
feature,  although  in  object-oriented  languages  the  exception  is 
normally  represented  with  an  object.  Exception  handling  existed 
before  object-oriented  languages. 

Exception  handling  isonly  lightly  introduced  and  used  in  this 
Volume;  Volume  2 (avail  able  from  www.BruceEckei.com)  has 
thorough  coverage  of  exception  handling. 
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Analysis  and  design 

The  object-oriented  paradigm  is  a new  and  different  way  of 
thinking  about  programming  and  many  foiks  have  troubi  eat  first 
knowing  how  to  approach  an  OOP  project.  Once  you  know  that 
everything  is  supposed  to  bean  object,  and  as  you  iearn  to  think 
more  in  an  object-oriented  styie,  you  can  begin  to  create  "good" 
desi  gns  that  take  advantage  of  aii  the  benefits  that  OOP  has  to 
offer. 

A method  (often  cai  ied  a methodology)  is  a set  of  processes  and 
heuristics  used  to  break  down  thecompiexity  of  a programming 
probiem.  Many  OOP  methods  have  been  formuiated  si  nee  the 
dawn  of  object-oriented  programming.  This  section  wiii  giveyou  a 
feei  for  what  you're  trying  to  accompiish  when  using  a method. 

Especiaiiy  in  OOP,  method oiogy  isafieid  of  many  experiments,  so 
it  is  important  to  understand  what  probiem  the  method  is  trying  to 
soive  before  you  consider  adopting  one.  This  is  parti cuiariy  true 
with  C-H-,  in  which  the  programming  ianguage  is  intended  to 
reduce  thecompiexity  (compared  toC)  invoived  in  expressing  a 
program.  This  may  in  fact  aiieviatethe  need  for  ever-more-compiex 
methodoiogies.  instead,  simpier  ones  may  suffice  in  C-H-for  a 
much  iargerciassof  probiemsthan  you  couid  handieusing  simpie 
methodoiogies  with  procedurai  ianguages. 

it'saiso  important  to  reaiize  that  the  term  "methodoiogy"  isoften 
too  grand  and  promises  too  much.  Whatever  you  do  now  when 
you  design  and  write  a program  is  a method,  it  may  be  your  own 
method,  and  you  may  not  be  conscious  of  doing  it,  but  it  is  a 
process  you  go  through  as  you  create,  if  it  is  an  effective  process,  it 
may  need  oniy  asmaii  tune-upto  work  with  C-H-.  if  you  are  not 
satisfied  with  your  productivity  and  the  way  your  programs  turn 
out,  you  may  want  to  consider  adopting  a formai  method,  or 
choosing  pieces  from  among  the  many  formai  methods. 

Whiie you're  going  through  the  deveiopment  process,  the  most 
important  issue  isthis:  Don't  getiost.  it's  easy  to  do.  Most  of  the 
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analysis  and  design  methods  are  intended  to  solvethe  largest  of 
problems.  Remember  that  most  projects  don't  fit  into  that  category, 
so  you  can  usually  have  successful  analysis  and  design  with  a 
relatively  smal  I subset  of  what  a method  recommends®.  But  some 
sort  of  process,  no  matter  how  limited,  will  generally  get  you  on 
your  way  in  a much  better  fashion  than  simply  beginning  to  code. 

It'salsoeasy  to  get  stuck,  to  fall  into  "analysis  paralysis,"  where 
you  feel  I ike  you  can't  move  forward  because  you  haven't  nailed 
down  every  little  detail  at  the  current  stage.  Remember,  no  matter 
how  much  analysis  you  do,  there  are  some  things  about  a system 
that  won't  reveal  themselves  until  design  time,  and  more  things 
that  won't  reveal  themselves  until  you're  coding,  or  not  even  until 
a program  is  up  and  running.  Because  of  this,  it's  crucial  to  move 
fairly  quickly  through  analysis  and  design,  and  to  implement  a test 
of  the  proposed  system. 

This  point  is  worth  emphasizing.  Becauseof  the  hi  story  we've  had 
with  procedural  languages,  it  is  commendable  that  a team  will 
want  to  proceed  carefully  and  understand  every  minute  detail 
before  movi ng  to  design  and  implementation.  Certainly,  when 
creating  a DBM  S,  it  pays  to  understand  a customer's  needs 
thoroughly.  But  a DBMS  is  in  a class  of  problems  that  is  very  well- 
posed  and  well -understood;  in  many  such  programs,  thedatabase 
structure /s  the  problem  to  be  tackled.  The  class  of  programming 
problem  discussed  in  this  chapter  is  of  the  "wild-card"  (my  term) 
variety,  in  which  the  solution  isn't  simply  re-forming  a well-known 
solution,  but  instead  involves  one  or  more  "wild-card  factors"  - 
elements  for  which  there  is  no  well-understood  previous  solution, 
and  for  which  research  is  necessary^.  Attempting  to  thoroughly 


® An  excellent  example  of  this \sUM  L Distilled,  by  Martin  Fowler  (Addison-Wesley 
2000),  which  reduces  the  sometimes-overwhelming  UML  process  to  a manageable 
subset. 

^ My  rule  of  thumb  for  estimating  such  projects:  If  there's  more  than  onewild  card, 
don't  even  try  to  plan  how  long  it'sgoing  totakeor  how  much  it  will  costuntil 
you've  created  a working  prototype.  There  are  too  many  degrees  of  freedom. 
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analyze  a wild-card  problenn  before  moving  into  design  and 
implementation  results  in  analysis  paralysis  because  you  don't 
have  enough  information  to  solve  this  kind  of  problem  during  the 
analysis  phase.  Solving  such  a problem  requires  iteration  through 
the  whole  cycle,  and  that  requires  risk-taking  behavior  (which 
makes  sense,  becauseyou'retrying  to  do  something  new  and  the 
potential  rewards  are  higher).  It  may  seem  I ike  the  risk  is 
compounded  by  "rushing"  into  a preliminary  implementation,  but 
it  can  instead  reduce  the  risk  in  a wild-card  project  because  you're 
finding  out  early  whether  a particular  approach  to  the  problem  is 
viable.  Product  development  is  risk  management. 

It's  often  proposed  that  you  "build  one  to  throw  away."  With  OOP, 
you  may  still  throw  part  of  it  away,  but  because  code  is 
encapsulated  into  classes,  during  thefirst  iteration  you  will 
inevitably  produce  some  useful  class  designs  and  develop  some 
worthwhile  ideas  about  the  system  design  that  do  not  need  to  be 
thrown  away.  Thus,  thefirst  rapid  pass  at  a problem  not  only 
produces  critical  information  for  the  next  analysis,  design,  and 
implementation  iteration,  it  also  creates  a code  foundation  for  that 
iteration. 

That  said,  if  you're  looking  at  a methodology  that  contains 
tremendous  detail  and  suggests  many  steps  and  documents,  it's 
still  difficult  to  know  when  to  stop.  Keep  in  mind  what  you're 
trying  to  discover: 

1.  What  are  the  objects?  (How  do  you  partition  your  project  into 
its  component  parts?) 

2 . What  are  thei  r i nterfaces?  (What  messages  do  you  need  to  be 
able  to  send  to  each  object?) 

If  you  come  up  with  nothing  more  than  the  objects  and  their 
interfaces,  then  you  can  write  a program.  For  various  reasons  you 
might  need  more  descriptions  and  documents  than  this,  but  you 
can't  get  away  with  any  less. 
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The  process  can  beundertaken  in  fivephases,  and  a phaseOthat  is 
just  the  initial  commitment  to  using  some  kind  of  structure. 

Phase  0:  Make  a plan 

You  must  firstdecidewhat  steps  you're  going  to  havein  your 
process.  ltsoundssimple(in  fact,  all  of  this  sounds  simple)  and  yet 
peopleoften  don't  make  this  decision  before  they  start  coding.  If 
your  plan  is  "let's  jump  in  and  start  coding,"  fine.  (Sometimes 
that's  appropriate  when  you  have  a well -understood  problem.)  At 
least  agree  that  this  isthe  plan. 

You  might  also  decideatthis  phase  that  some  additional  process 
structure  is  necessary,  but  not  the  whole  nine  yards. 

U nderstandably  enough,  some  programmers  I i ke  to  work  i n 
"vacation  mode"  in  which  no  structure  is  imposed  on  the  process 
of  developing  their  work;  "It  will  bedonewhen  it'sdone."  Thiscan 
beappealing  for  awhile,  but  I've  found  that  having  a few 
milestones  along  the  way  helps  to  focus  and  galvanize  your  efforts 
around  those  milestones  instead  of  being  stuck  with  the  single  goal 
of  "finish  the  project."  In  addition,  it  divides  the  project  into  more 
bite-sized  pieces  and  makes  it  seem  less  threatening  (plusthe 
mi  I estones  offer  more  opportu niti  es  for  cel  ebrati  on). 

When  I began  to  study  story  structure  (so  that  I will  someday  write 
a novel ) I was  i ni ti  al  I y resi  stant  to  the  i dea  of  structu re,  feel  i ng  that 
when  I wrote  I simply  let  it  flow  onto  the  page.  But  I later  realized 
that  when  I writeaboutcomputersthestructure  is  clear  enough  so 
that  I don't  think  much  about  it.  But  I still  structure  my  work,  albeit 
only  semi-consciously  in  my  head.  So  even  if  you  think  that  your 
plan  istojust  start  coding,  you  still  somehow  go  through  the 
subsequent  phases  while  asking  and  answering  certain  questions. 

The  mission  statement 

Any  system  you  build,  no  matter  how  complicated,  has  a 
fundamental  purpose,  the  business  that  it's  in,  the  basic  need  that  it 
satisfies.  If  you  can  look  past  the  user  interface,  the  hardware-  or 
system-specific  details,  the  coding  algorithms  and  the  efficiency 
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problems,  you  will  eventually  find  the  core  of  its  being,  simpleand 
straightforward.  Like  the  so-called  high  concqjt  from  a Hollywood 
movie,  you  can  describe  it  in  one  or  two  sentences.  This  pure 
description  is  the  starting  point. 

The  high  concept  is  quite  important  because  it  sets  the  tone  for  your 
project;  it's  a mission  statement.  You  won't  necessarily  get  it  right 
the  fi  rst  ti  me  (you  may  be  i n a I ater  phase  of  the  project  before  it 
becomes  completely  clear),  but  keep  trying  until  it  feels  right.  For 
example,  in  an  air-traffic  control  system  you  may  start  out  with  a 
high  concept  focused  on  thesystem  that  you're  building:  "The 
tower  program  keeps  track  of  the  aircraft."  But  consider  what 
happens  when  you  shrinkthesystemtoa  very  small  airfield; 
perhaps  there's  only  a human  controller  or  noneat  all.  A more 
useful  model  won't  concern  the  solution  you're  creating  as  much  as 
it  describes  the  problem:  "Aircraft  arrive,  unload,  service  and 
reload,  and  depart." 

Phase  1:  What  are  we  making? 

In  the  previous  generation  of  program  design  (called  procedural 
design),  thisiscalled  "creating  the  reqfu/rementsana/ys/s  and  system 
specification."  These,  of  course,  were  pi  aces  to  get  lost; 
intimidatingly-named  documents  that  could  become  big  projects  in 
their  own  right.  Their  intention  was  good,  however.  The 
requ  i rements  anal ysi s says  " M ake  a I i st  of  the  gu i del  i nes  we  wi  1 1 
use  to  know  when  the  job  is  done  and  the  customer  is  satisfied." 
Thesystem  specification  says  "Here's  a description  of  what  the 
program  will  do  (not  how)  to  satisfy  the  requirements."  The 
requirements  analysis  is  really  a contract  between  you  and  the 
customer  (even  if  the  customer  works  within  your  company  or  is 
some  other  object  or  system).  The  system  specification  is  a top-level 
exploration  into  the  problem  and  in  some  sense  a discovery  of 
whether  it  can  be  done  and  how  long  it  will  take.  Since  both  of 
these  will  require  consensus  among  people  (and  because  they  will 
usually  change  over  time),  I think  it's  best  to  keep  them  as  bare  as 
possible-  ideally,  to  lists  and  basic  diagrams- to  save  time.  You 
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might  have  other  constrai  nts  that  require  you  to  expand  them  into 
bigger  documents,  but  by  keeping  the  initial  document  small  and 
concise,  it  can  be  created  in  a few  sessions  of  group  brainstorming 
with  a leader  who  dynamically  creates  the  description.  This  not 
only  solicits  input  from  everyone,  it  also  fosters  initial  buy-in  and 
agreement  by  everyone  on  the  team.  Perhaps  most  importantly,  it 
can  kick  off  a project  with  a lot  of  enthusiasm. 

It's  necessary  to  stay  focused  on  the  heart  of  what  you're  try!  ng  to 
accomplish  in  this  phase:  determine  what  the  system  is  supposed  to 
do.  The  most  valuable  tool  for  this  is  a collection  of  what  are  cal  led 
"use  cases."  U se  cases  identify  key  features  i n the  system  that  wi  1 1 
reveal  some  of  the  fundamental  classes  you'll  be  using.  These  are 
essentially  descriptive  answers  to  questions  I ike^: 

• "Who  will  usethis system?" 

• "What  can  those  actors  do  with  the  system?" 

• "How  does  this  actor  do  that  with  this  system?" 

• "How  else  might  this  work  if  someone  else  were  doing  this, 
or  if  the  same  actor  had  a different  objective?"  (to  reveal 
variations) 

• "What  problems  might  happen  while  doing  this  with  the 
system?"  (to  reveal  exceptions) 

If  you  are  design!  ng  an  auto-tel  ler,  for  example,  the  use  case  for  a 
parti cu  I ar  aspect  of  the  f u ncti  onal  i ty  of  the  system  i s abl e to 
describewhattheauto-tellerdoesin  every  possible  situation.  Each 
of  these  "situations"  is  referred  to  as  a scenario,  and  a use  case  can 
be  considered  a collection  of  scenarios.  You  can  think  of  a scenario 
asa  question  that  starts  with:  "What  does  the  system  do  if...?"  For 
example,  "What  does  the  auto-tel  ler  do  if  a customer  hasjust 
deposited  a check  within  24  hours  and  there's  not  enough  in  the 
account  without  the  check  to  provide  the  desired  withdrawal?" 


^Thanks  for  help  from  James  H jarrett. 
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Use  case  diagrams  are  intentionally  simple  to  prevent  you  from 
getting  bogged  down  in  system  implementation  details 
prematurely: 


Each  stick  person  represents  an  "actor,"  which  istypically  a human 
or  some  other  ki  nd  of  free  agent.  (These  can  even  be  other 
computer  systems,  as  is  the  case  with  "ATM .")  The  box  represents 
the  boundary  of  your  system.  The  el  I i pses  represent  the  use  cases, 
which  are  descriptions  of  valuable  work  that  can  be  performed 
with  the  system.  The  I i nes  between  the  actors  and  the  use  cases 
represent  the  i nteractions. 

It  doesn't  matter  how  the  system  isactually  implemented,  aslong 
as  it  looks  I ike  this  to  theuser. 

A use  case  does  not  need  to  be  terribly  complex,  even  if  the 
underlying  system  is  complex.  It  is  only  intended  to  show  the 
system  as  it  appears  to  the  user.  For  example: 
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Greenhouse 

Maintain 
Growing 
Temperature 


Gardener 


The  use  cases  produce  the  requirements  specifications  by 
determining  all  the  interactions  that  the  user  may  have  with  the 
system.  Y ou  try  to  d i scover  a f u 1 1 set  of  u se  cases  for  you  r system, 
and  once  you've  done  that  you  have  the  core  of  what  the  system  is 
supposed  to  do.  The  nice  thing  about  focusing  on  use  cases  is  that 
they  always  bring  you  back  to  the  essentials  and  keep  you  from 
drifting  off  into  issues  that  aren't  critical  for  getting  the  job  done. 
That  is,  if  you  haveafull  set  of  use  cases  you  can  describe  your 
system  and  move  onto  the  next  phase.  You  probably  won't  get  it  all 
figured  out  perfectly  on  thefirsttry,  butthat'sOK.  Everything  will 
reveal  itself  in  time,  and  if  you  demand  a perfect  system 
specification  at  this  point  you'll  get  stuck. 

If  you  get  stuck,  you  can  kick-start  this  phase  by  using  a rough 
approximation  tool:  describe  the  system  in  afew  paragraphs  and 
then  look  for  nouns  and  verbs.  The  nouns  can  suggest  actors, 
context  of  the  use  case  (e.g.  "lobby"),  or  artifacts  manipulated  in  the 
use  case.  Verbs  can  suggest  interactions  between  actors  and  use 
cases,  and  specify  steps  within  the  use  case.  You'll  also  discover 
that  nounsand  verbs  produce  objects  and  messages  during  the 
design  phase  (and  notethatusecasesdescribe  interactions  between 
subsystems,  so  the  "noun  and  verb"  technique  can  be  used  only  as 
a brainstorming  tool  as  it  does  not  generate  use  cases) 

The  boundary  between  a use  case  and  an  actor  can  point  out  the 
existenceof  a user  interface,  but  it  does  not  define  such  a user 


® More  information  on  use  cases  can  be  found  \n  Applying  U seCases  by  Schneider  & 
Winters  (Addison-Wesley  1998)  and  U seCaseD riven  Object  M odeling  with  UM  L by 
Rosenberg  (Addison-Wesley  1999). 
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interface.  For  a process  of  defining  and  creating  user  interfaces,  see 
Softwarefor  U seby  Larry  Constantine  and  Lucy  Lockwood, 

(Addison  Wesley  Longman,  1999)  or  goto  www.ForUse.com. 

Although  it's  a black  art,  at  this  point  some  kind  of  basic 
scheduling  is  important.  You  now  have  an  overview  of  what  you're 
building  so  you'll  probably  beableto  get  some  idea  of  how  long  it 
will  take.  A lotof  factors  come  into  play  here.  If  you  estimatea  long 
schedulethen  the  company  might  decide  not  to  build  it  (and  thus 
use  their  resources  on  something  more  reasonable  - that's  a good 
thing).  Or  a manager  might  have  already  decided  how  long  the 
project  should  takeand  will  try  to  influence  your  estimate.  But  it's 
best  to  havean  honest  schedule  from  the  beginning  and  deal  with 
the  tough  decisions  early.  There  have  been  a lot  of  attempts  to  come 
up  with  accurate  scheduling  techniques  (liketechniques  to  predict 
the  stock  market),  but  probably  the  best  approach  is  to  rely  on  your 
experience  and  intuition.  Get  a gut  feeling  for  how  long  it  will 
really  take,  then  double  that  and  add  10  percent.  Your  gut  feeling  is 
probably  correct;  you  can  get  something  working  in  that  time.  The 
"doubling"  will  turn  that  into  something  decent,  and  the  10  percent 
will  deal  with  the  final  polishing  and  details^  However  you  want 
to  explain  it,  and  regardless  of  the  moans  and  manipulations  that 
happen  when  you  reveal  such  a schedule,  it  just  seems  to  work  out 
that  way. 

Phase  2:  How  will  we  build  it? 

In  this  phase  you  mustcomeup  with  a design  that  describes  what 
the  cl  asses  I ook  I i ke  and  how  they  w i 1 1 i nteract.  A n excel  I ent 
technique  in  determining  classes  and  interactions  \s  the  Class- 
Responsibility-Collaboration  (CRC)  card.  Partof  the  value  of  this  tool 


M y personal  take  on  this  has  changed  lately.  Doubling  and  adding  lOpercentwill 
giveyou  a reasonably  accurate  estimate  (assuming  there  are  not  too  many  wild-card 
factors),  but  you  still  haveto  work  quitediligently  to  finish  inthattime.  If  you  want 
time  to  really  make  it  elegant  and  to  enjoy  yourself  in  the  process,  the  correct 
multiplier  is  more  likethree  or  four  times,  I believe. 
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is  that  it's  so  low-tech:  you  start  out  with  a set  of  blank  3"  by  5" 
cards,  and  you  write  on  thenn.  Each  card  represents  a single  class, 
and  on  the  card  you  write: 

1.  The  name  of  the  cl  ass.  It's  important  that  this  name  capture 
the  essence  of  what  the  cl  ass  does,  so  that  it  makes  sense  at  a 
glance. 

2.  The  "responsibilities"  of  the  cl  ass:  what  it  should  do.  This  can 
typically  be  summarized  by  just  stating  the  names  of  the 
member  functions  (si  nee  those  names  should  be  descri  pti  ve 
in  a good  design),  but  it  does  not  preclude  other  notes.  If  you 
need  to  seed  the  process,  look  at  the  problem  from  a lazy 
programmer's  standpoint:  What  objects  would  you  liketo 
magically  appear  to  solve  your  problem? 

3.  The  "collaborations"  of  the  class:  what  other  classes  does  it 
interact  with?  "Interact"  is  an  intentionally  broad  term;  it 
could  mean  aggregation  or  simply  that  some  other  object 
exists  that  will  perform  services  for  an  object  of  the  class. 
Collaborations  should  also  consider  the  audience  for  this 
class.  For  example,  if  you  create  a class  Firecracker  who  is 
going  to  observe  it,  a Chemistor  a Spectator Theformer 
will  want  to  know  what  chemicals  go  into  the  construct! on, 
and  the  latter  will  respond  to  the  colors  and  shapes  released 
when  it  explodes. 

You  may  feel  likethecardsshould  be  bigger  because  of  all  the 
information  you'd  I ike  to  get  on  them,  but  they  are  intentionally 
small,  not  only  to  keep  your  classes  small  but  also  to  keep  you  from 
getting  into  too  much  detail  too  early.  If  you  can't  fit  all  you  need  to 
know  about  a class  on  a small  card,  theclassistoo  complex  (either 
you'regetting  too  detailed,  or  you  should  create  more  than  one 
class).  The  ideal  class  should  be  understood  at  a glance.  The  idea  of 
CRC  cards  isto  assist  you  in  coming  up  with  a fi  rst  cut  of  the 
design  so  that  you  can  get  the  big  picture  and  then  refine  your 
design. 
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Oneof  the  great  benefits  of  CRC  cards  is  in  communication,  it's 
best  done  reai-time,  in  a group,  without  computers.  Each  person 
takes  responsibiiity  for  severai  ci asses  (which  at  first  have  no 
namesorother  information).  You  run  a iivesimuiation  by  soiving 
one  scenari o at  a ti  me,  d eci  d i ng  w hi ch  messages  are  sent  to  the 
various  objects  to  satisfy  each  scenario.  As  you  go  through  this 
process,  you  discover  the  ci  asses  that  you  need  aiong  with  their 
responsibiiitiesand  coii adorations,  and  you  fiii  out  the  cards  as  you 
do  this.  When  you've  moved  through  aii  theuse cases,  you  shouid 
have  a fai riy  compi ete fi  rst  cut  of  your  desi gn. 

Before  i began  using  CRC  cards,  the  most  successfui  consuiting 
experiences  i had  when  coming  up  with  an  initiai  design  invoived 
standing  in  front  of  a team,  who  hadn't  buiit  an  OOP  project  before, 
and  drawing  objects  on  a whiteboard.  Wetaiked  about  how  the 
objects  shouid  communicate  with  each  other,  and  erased  some  of 
them  and  repiaced  them  with  other  objects.  Effectiveiy,  i was 
managing  aii  the"CRC  cards"  on  the  whiteboard.  The  team  (who 
knew  what  the  project  was  supposed  to  do)  actuaiiy  created  the 
design;  they  "owned"  the  design  rather  than  having  it  given  to 
them.  Aii  i was  doing  was  guiding  the  process  by  asking  the  right 
questions,  trying  out  the  assumptions,  and  taking  the  feed  back 
from  the  team  to  modify  those  assumptions.  The  true  beauty  of  the 
process  was  that  the  team  iearned  how  to  do  object-oriented  design 
not  by  reviewing  abstract  examp ies,  but  by  working  on  the  one 
design  that  was  most  interesting  to  them  at  that  moment:  theirs. 

Onceyou'vecomeup  with  asetof  CRC  cards,  you  may  want  to 
createa  moreformai  description  of  your  design  using  UML^i.  You 
don't  need  to  use  U ML,  but  it  can  beheipfui,  especiaiiy  if  you  want 
to  put  up  a diagram  on  the  waii  for  everyone  to  ponder,  which  is  a 
good  idea.  An  aiternati  veto  UML  isatextuai  description  of  the 


For  starters,  I recommend  the  aforementioned  UML  Distilled. 
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objects  and  their  interfaces,  or,  depending  on  your  programming 
ianguage,  the  code  itseif^^. 

UM  L aiso  provides  an  additionai  diagramming  notation  for 
describingthedynamic  modei  of  your  system.  This  is  heipfui  in 
situations  in  which  the  state  transitions  of  a system  or  subsystem 
are  dominant  enough  that  they  need  their  own  diagrams  (such  as  in 
a controi  system).  You  may  aiso  need  to  describe  the  data 
structures,  for  systems  or  subsystems  in  which  data  is  a dominant 
factor  (such  as  a database). 

You'ii  know  you're  done  with  phase  2 when  you  have  described 
the  objects  and  thei  r i nterfaces.  Wei  i , most  of  them  - there  are 
usuai  iy  a few  that  si  ip  through  the  cracks  and  don't  make 
themseives  known  untii  phase  3.  But  that's  OK.  Aii  you  are 
concerned  with  isthatyou  eventuaiiy  discover  aii  of  your  objects, 
it's  niceto  discover  them  eariy  in  the  process  but  OOP  provides 
enough  structure  so  that  it's  not  so  bad  if  you  discover  them  iater. 
in  fact,  the  design  of  an  object  tends  to  happen  in  five  stages, 
throughout  the  process  of  program  deveiopment. 

Five  stages  of  object  design 

The  design  iifeof  an  object  is  not  iimited  to  the  time  when  you're 
writing  the  program,  instead,  the  design  of  an  object  appears  over  a 
sequence  of  stages,  it's  heipfui  to  havethis  perspective  because  you 
stop  expecting  perfection  right  away;  instead,  you  reaiize that  the 
understanding  of  what  an  object  does  and  what  itshouid  iook  iike 
happens  over  time.  This  view  aiso  appiies  to  the  design  of  various 
types  of  programs;  the  pattern  for  a parti  cuiar  type  of  program 
emerges  through  struggiing  again  and  again  with  that  probiem 
{Design  Patterns  are  covered  in  Voiume2).  Objects,  too,  havetheir 
patterns  that  emerge  through  understanding,  use,  and  reuse. 


^ Python  (www.Python.org)  is  often  used  as  "executable  pseudocode." 
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1.  Object  discoveryJhisstageoccurs  during  the  initial 
analysis  of  a program.  Objects  may  bediscovered  by  looking  for 
external  factors  and  boundaries,  duplication  of  elements  in  the 
system,  and  the  smallest  conceptual  units.  Some  objects  are  obvious 
if  you  al  ready  have  a set  of  cl  ass  I i brari  es.  Commonal  ity  between 
classes  suggesting  base  classes  and  inheritance  may  appear  right 
away,  or  later  in  the  design  process. 

2.  Object  assemblyAsyou're  building  an  object  you'll 
discover  the  need  for  new  membersthat  didn't  appear  during 
discovery.  The  internal  needs  of  the  object  may  require  other 
cl  asses  to  support  it. 

3.  System  constructionOnce  again,  more  requirements  for 
an  object  may  appear  at  this  later  stage.  As  you  learn,  you  evolve 
your  objects.  The  need  for  communication  and  interconnection  with 
other  objects  in  the  system  may  change  the  needs  of  your  classes  or 
require  new  classes.  For  example,  you  may  discover  the  need  for 
faci  I itator  or  hel  per  cl  asses,  such  as  a I i nked  I i st,  that  contai  n I itti  e 
or  no  state  information  and  simply  help  other  cl  asses  function. 

4.  System  extension  As  you  add  new  features  to  a system 
you  may  discover  that  your  previous  design  doesn't  support  easy 
system  extension.  With  this  new  information,  you  can  restructure 
parts  of  the  system,  possibly  adding  new  cl  asses  or  class 
hierarchies. 

5.  Object  reuse.Thisisthereal  stress  test  for  a cl  ass.  If 
someone  tries  to  reuse  it  in  an  entirely  new  situation,  they'll 
probably  discover  some  shortcomings.  As  you  change  a cl  ass  to 
adapt  to  more  new  programs,  the  general  principles  of  the  class 
will  become  clearer,  until  you  haveatruly  reusabletype.  However, 
don't  expect  most  objects  from  a system  design  to  be  reusable-  it  is 
perfecti y acceptabi e for  the  bu I k of  you  r objects  to  be  system- 
specific.  Reusable  types  tend  to  be  less  common,  and  they  must 
solve  more  general  problems  in  order  to  be  reusable. 
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Guidelines  for  object  development 

These  stages  suggest  some  guidelines  when  thinking  about 
devel  opi  ng  you  r cl  asses: 

1.  Let  a specific  problem  generate  a cl  ass,  then  let  the  cl  ass  grow 
and  mature  during  the  solution  of  other  problems. 

2 . Remember,  d i scoveri  ng  the  cl  asses  you  need  (and  thei  r 
interfaces)  isthe  majority  of  the  system  design.  If  you  already 
had  those  cl  asses,  this  would  bean  easy  project. 

3.  Don't  force  yourself  to  know  everything  at  the  beginning; 
learn  as  you  go.  This  will  happen  anyway. 

4.  Start  programming;  get  something  working  so  you  can  prove 
or  disprove  your  design.  Don't  fear  that  you'll  end  up  with 
procedural-style  spaghetti  code  - classes  partition  the 
problem  and  help  control  anarchy  and  entropy.  Bad  classes 
do  not  break  good  classes. 

5.  Always  keep  it  simple.  Littleclean  objects  with  obvious 
utility  are  better  than  big  complicated  interfaces.  When 
decision  points  come  up,  use  an  Occam's  Razor  approach: 
Consider  the  choices  and  select  the  one  that  issimplest, 
because  si  mpl  e cl  asses  are  al  most  always  best.  Start  smal  I 
and  simple,  and  you  can  expand  the  cl  ass  interface  when  you 
understand  it  better,  but  as  time  goes  on,  it's  difficult  to 
remove  el  ements  from  a cl  ass. 

Phase  3:  Build  the  core 

Thisistheinitial  conversion  from  the  rough  design  intoa 
compiling  and  executing  body  of  codethatcan  be  tested,  and 
especially  that  will  prove  or  disprove  your  architecture.  This  is  not 
a one-pass  process,  but  rather  the  beginning  of  a series  of  steps  that 
will  iteratively  build  thesystem,  as  you'll  see  in  phase4. 

Your  goal  is  to  find  the  core  of  your  system  architecture  that  needs 
to  be  implemented  in  order  to  generate  a running  system,  no  matter 
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how  incompletethat  system  is  in  this  initial  pass.  You're  creating  a 
framework  that  you  can  build  upon  with  further  iterations.  You're 
also  performing  the  first  of  many  system  integrations  and  tests,  and 
gi  vi  ng  the  stakehol  ders  feed  back  about  w hat  thei  r system  w i 1 1 1 ook 
likeand  how  it  is  progressing.  Ideally,  you  are  also  exposing  some 
of  the  critical  risks.You'll  probably  also  discover  changes  and 
improvements  that  can  be  madeto  your  original  architecture - 
things  you  would  not  have  learned  without  implementing  the 
system. 

Part  of  building  the  system  isthe  reality  check  that  you  get  from 
testing  against  your  requirements  analysis  and  system  specification 
(in  whatever  form  they  exist).  M ake  sure  that  your  tests  verify  the 
requirements  and  use  cases.  When  the  core  of  the  system  isstable, 
you're  ready  to  move  on  and  add  more  functionality. 

Phase  4:  Iterate  the  use  cases 

Oncethe  core  framework  is  running,  each  feature  set  you  add  isa 
small  project  in  itself.  You  add  a feature  set  during  an  iteration,  a 
reasonably  short  period  of  development. 

How  big  isan  iteration?  Ideally,  each  iteration  lasts  one  to  three 
weeks  (this  can  vary  based  on  the  implementation  language).  At 
the  end  of  that  period,  you  have  an  integrated,  tested  system  with 
more  functionality  than  it  had  before.  But  what's  particularly 
interesting  is  the  basis  for  the  iteration:  a single  use  case.  Each  use 
case  is  a package  of  related  functionality  that  you  build  into  the 
system  all  at  once,  during  one  iteration.  Not  only  does  this  give  you 
a better  idea  of  what  the  scope  of  a use  case  should  be,  but  it  also 
gives  more  validation  to  the  idea  of  a use  case,  si  nee  the  concept 
isn't  discarded  after  analysis  and  design,  but  instead  it  isa 
fundamental  unit  of  development  throughout  the  software- 
building  process. 

You  stop  iterating  when  you  achieve  target  functionality  or  an 
external  deadline  arrives  and  the  customer  can  be  satisfied  with  the 
current  version.  (Remember,  software  is  a subscription  business.) 
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Because  the  process  is  iterative,  you  have  many  opportunities  to 
ship  a product  instead  of  a single  end  point;  open-source  projects 
work  exclusively  in  an  iterative,  high-feedback  environment,  which 
is  precisely  what  makes  them  successful. 

An  iterative  development  process  is  valuablefor  many  reasons. 

You  can  reveal  and  resolve  critical  risks  early,  the  customers  have 
ampi  e opportu  ni  ty  to  change  the!  r mi  nds,  programmer  sati  sfacti  on 
is  higher,  and  the  project  can  be  steered  with  more  precision.  But  an 
additional  important  benefit  is  the  feed  back  to  the  stakeholders, 
who  can  see  by  the  current  state  of  the  product  exactly  where 
everything  lies.  This  may  reduce  or  eliminate  the  need  for  mind- 
numbing  status  meetings  and  increase  the  confidence  and  support 
from  the  stakeholders. 

Phase  5:  Evolution 

This  is  the  point  in  the  development  cycle  that  has  traditionally 
been  called  "maintenance,"  a catch-all  term  that  can  mean 
everything  from  "getting  it  to  work  the  way  it  was  really  supposed 
to  in  the  first  place"  to  "adding  features  that  the  customer  forgot  to 
mention"  to  the  more  traditional  "fixing  the  bugs  that  show  up" 
and  "adding  new  features  as  the  need  arises."  So  many 
misconceptions  have  been  applied  to  the  term  "maintenance"  that 
it  has  taken  on  a slightly  deceiving  quality,  partly  because  it 
suggests  that  you've  actually  builta  pristine  program  and  all  you 
need  to  do  is  change  parts,  oil  it,  and  keep  it  from  rusting.  Perhaps 
there's  a better  term  to  describe  what's  going  on. 

I'll  usethetermei/o/ut/on^TThatis,  "You  won't  get  it  right  thefirst 
time,  so  give  yourself  the  latitude  to  learn  and  to  go  back  and  make 
changes."  You  might  need  to  make  a lot  of  changes  as  you  learn 
and  understand  the  problem  more  deeply.  The  elegance  you'll 


At  I east  one  aspect  of  evolution  iscovered  in  Martin  Fowler's  book  Refactoring: 
improving  thedesign  of  existing  code  (Addison-Wesley  1999).  Be  forewarned  that  this 
book  usesjava  examples  exclusiveiy. 
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produce  if  you  evolve  until  you  get  it  right  will  payoff,  both  in  the 
short  and  the  long  term.  Evolution  is  where  your  program  goes 
from  good  to  great,  and  wherethose  issues  that  you  didn't  really 
understand  in  the  first  pass  become  cl  ear.  It's  also  where  your 
classes  can  evolve  from  single-project  usage  to  reusable  resources. 

What  it  means  to  "get  it  right"  isn't  just  that  the  program  works 
according  to  the  requirements  and  the  use  cases.  It  also  means  that 
the  internal  structure  of  the  code  makes  sense  to  you,  and  feels  I ike 
it  fits  together  well,  with  no  awkward  syntax,  oversized  objects,  or 
ungainly  exposed  bits  of  code.  In  addition,  you  must  have  some 
sense  that  the  program  structurewill  survive  the  changes  that  it 
will  inevitably  go  through  during  its  lifetime,  and  that  those 
changes  can  be  made  easily  and  cleanly.  This  is  no  small  feat.  You 
must  not  only  understand  what  you're  building,  but  also  how  the 
program  will  evolve(what  I call  the  vector  ofchange^'^}.  Fortunately, 
object-oriented  programming  languages  are  particularly  adept  at 
supporting  this  kind  of  continuing  modification  - the  boundaries 
created  by  the  objects  are  what  tend  to  keep  the  structure  from 
breaking  down.  They  also  allow  you  to  make  changes  - ones  that 
would  seem  drastic  in  a procedural  program- without  causing 
earthquakes  throughout  your  code.  In  fact,  support  for  evolution 
might  be  the  most  important  benefit  of  OOP. 

With  evolution,  you  create  something  that  at  least  approximates 
what  you  think  you're  building,  and  then  you  kick  the  tires, 
compare  it  to  your  requirements  and  see  where  it  falls  short.  Then 
you  can  go  back  and  fix  it  by  redesigning  and  re-implementing  the 
portions  of  the  program  that  didn't  work  right^s.  You  might 


^^This  term  is  explored  intheDes/gn  Patterns  chapter  in  Volume  2. 

^^This  is  something  like  "rapid  prototyping,"  where  you  were  supposed  to  build  a 
quick-and-dirty  version  so  that  you  could  learn  about  the  system,  and  then  throw 
away  your  prototype  and  build  it  right.  The  trouble  with  rapid  prototyping  is  that 
people  didn't  throw  away  the  prototype,  but  instead  built  upon  it.  Combined  with 
the  lack  of  structure  in  procedural  programming,  this  often  produced  messy  systems 
that  were  expensive  to  mai  ntai  n. 
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actually  need  tosolvetheproblenn,  or  an  aspect  of  the  problenn, 
several  times  before  you  hit  on  the  right  solution.  (A  study  of 
Design  Patterns,  described  in  Volume 2,  isusually  helpful  here.) 

Evolution  also  occurs  when  you  build  a system,  see  that  it  matches 
your  requirements,  and  then  discover  it  wasn't  actually  what  you 
wanted.  When  you  see  the  system  in  operation,  you  find  that  you 
really  wanted  to  solve  a different  problem.  If  you  think  this  kind  of 
evolution  is  going  to  happen,  then  you  owe  it  to  yourself  to  build 
your  first  version  as  quickly  as  possible  so  you  can  find  out  if  it  is 
indeed  what  you  want. 

Perhaps  the  most  important  thing  to  remember  is  that  by  default  - 
by  definition,  really  - if  you  modify  a cl  ass  then  its  super-  and 
subclasses  will  still  function.  You  need  not  fear  modification 
(especially  if  you  have  a built-in  setof  unit  tests  to  verify  the 
correctness  of  your  modifications).  Modification  won't  necessarily 
break  the  program,  and  any  change  in  the  outcome  will  delimited 
to  subclasses  and/  or  specific  collaborators  of  the  cl  ass  you  change. 

Plans  pay  off 

Of  course  you  wouldn't  build  a house  without  a lot  of  carefully- 
drawn  plans.  If  you  build  a deck  or  a dog  house,  your  plans  won't 
be  so  elaborate  but  you'll  probably  still  startwith  some  kind  of 
sketches  to  guide  you  on  your  way.  Software  development  has 
gone  to  extremes.  Fora  longtime,  people  didn't  have  much 
structure  in  their  development,  but  then  big  projects  began  failing. 
In  reaction,  weended  up  with  methodologies  that  had  an 
intimidating  amount  of  structure  and  detail,  primarily  intended  for 
those  big  projects.  These  methodol  ogies  were  too  scary  to  use-  it 
looked  I ike  you'd  spend  all  your  time  writing  documents  and  no 
time  programming.  (This  was  often  the  case.)  I hopethat  what  I've 
shown  you  here  suggests  a middlepath  - a sliding  scale.  Use  an 
approach  that  fits  your  needs  (and  your  personality).  No  matter 
how  minimal  you  choose  to  make  it,  some  kind  of  plan  will  make  a 
big  improvement  in  your  project  as  opposed  to  no  plan  at  all. 
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Remember  that,  by  most  esti  mates,  over  50  percent  of  projects  fai  I 
(some  estimates  go  up  to  70  percent!). 

By  following  a plan  - preferably  one  that  is  simple  and  brief  - and 
coming  up  with  design  structure  before  coding,  you'll  discover  that 
things  fall  together  far  more  easily  than  if  you  dive  in  and  start 
hacking,  and  you'll  also  real ize a great  deal  of  satisfaction.  It's  my 
experience  that  coming  up  with  an  elegant  solution  is  deeply 
satisfying  at  an  entirely  different  level;  it  feels  closer  to  art  than 
technology.  And  elegance  always  pays  off;  it's  not  a frivolous 
pursuit.  Not  only  does  it  give  you  a program  that's  easier  to  build 
and  debug,  but  it's  also  easier  to  understand  and  maintain,  and 
that's  where  the  financial  value  lies. 


Extreme  programming 

I have  studied  analysis  and  design  techniques,  on  and  off,  si  nee  I 
was  in  graduateschool.  The  concept  of  Extreme Programm/ngi(XP)  is 
the  most  radical,  and  delightful,  that  I've  seen.  You  can  find  it 
chronicled  in  Extreme  Programming  Explained  by  Kent  Beck 
(Addison-Wesley  2000)  and  on  the  Web  at  www.xprogramming.com. 

XP  is  both  a philosophy  about  programming  work  and  a set  of 
guidelines  to  do  it.  Someof  these  gui  delines  are  reflected  in  other 
recent  methodologies,  but  the  two  most  important  and  distinct 
contributions,  in  my  opinion,  are  "write  tests  first"  and  "pair 
programming."  Although  he  argues  strongly  for  the  whole  process. 
Beck  points  out  that  if  you  adopt  only  these  two  practices  you'll 
greatly  improve  your  productivity  and  reliability. 

Write  tests  first 

Testing  has  traditionally  been  relegated  to  the  last  part  of  a project, 
after  you've  "gotten  everything  working,  but  just  to  be  sure."  It's 
implicitly  had  a low  priority,  and  people  who  specialize  in  it  have 
not  been  given  a lot  of  status  and  have  often  even  been  cordoned 
off  in  a basement,  away  from  the  "real  programmers."  Test  teams 
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have  responded  in  kind,  going  so  far  as  to  wear  black  clothing  and 
cackling  with  glee  whenever  they  broke  something  (to  be  honest, 
I've  had  thisfeeling  myself  when  breaking  C-H- compilers). 

XP  completely  revolutionizestheconcept  of  testing  by  giving  it 
equal  (or  even  greater)  priority  than  the  code.  In  fact,  you  write  the 
tests  beforeyou  write  the  codethat's  being  tested,  and  the  tests  stay 
with  the  code  forever.  The  tests  must  be  executed  successfully 
every  time  you  do  an  integration  ofthe  project  (which  is  often, 
sometimes  more  than  once  a day). 

Writing  tests  first  has  two  extremely  important  effects. 

First,  it  forces  a clear  definition  of  the  interface  of  a cl  ass.  I'veoften 
suggested  that  people  "imagine  the  perfect  cl  ass  to  solve  a 
particular  problem"  asatool  when  trying  to  design  thesystem.The 
XP  testing  strategy  goes  further  than  that  - it  specifies  exactly  what 
the  cl  ass  must  I ook  I i ke,  to  the  consu  mer  of  that  cl  ass,  and  exacti  y 
how  the  class  must  behave.  In  no  uncertain  terms.  You  can  write  all 
theprose,  or  create  all  the  diagrams  you  want  describing  how  a 
class  should  behave  and  what  it  looks  I ike,  but  nothing  is  as  real  as 
a set  of  tests.  The  former  is  a wish  list,  but  the  tests  are  a contract 
that  is  enforced  by  the  compiler  and  the  running  program.  It's  hard 
to  imagine  a more  concrete  description  of  a cl  ass  than  the  tests. 

While  creating  the  tests,  you  areforced  to  completely  think  out  the 
class  and  will  often  discover  needed  functionality  that  might  be 
missed  during  thethought  experimentsof  UML  diagrams,  CRC 
cards,  use  cases,  etc. 

The  second  i mportant  effect  of  writi  ng  the  tests  fi  rst  comes  from 
running  the  tests  every  ti  me  you  do  a build  of  your  software.  This 
activity  gives  you  the  other  half  of  the  testing  that's  performed  by 
the  compiler.  If  you  look  at  the  evolution  of  programming 
languages  from  this  perspective,  you'll  see  that  the  real 
improvements  in  the  technology  have  actually  revolved  around 
testing.  Assembly  language  checked  only  for  syntax,  butC  imposed 
some  semantic  restrictions,  and  these  prevented  you  from  making 
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certain  types  of  mistakes.  OOP  languages  impose  even  more 
semantic  restrictions,  which  if  you  think  about  it  are  actually  forms 
of  testing.  "Is  this  data  type  being  used  properly?  Isthisfunction 
being  called  properly?"  arethe  kinds  of  tests  that  are  being 
performed  by  the  compi  ler  or  run-ti  me  system.  We've  seen  the 
results  of  having  these  tests  built  into  the  language:  people  have 
been  ableto  write  more  compi  ex  systems,  and  get  them  to  work, 
with  much  less  time  and  effort.  I've  puzzled  over  why  this  is,  but 
now  I realize  it's  the  tests:  you  do  something  wrong,  and  the  safety 
netof  the  built-in  tests  tel  Is  you  there's  a problem  and  points  you  to 
where  it  is. 

But  the  built-in  testing  afforded  by  the  design  of  the  language  can 
only  go  so  far.  At  some  point,  you  must  step  in  and  add  the  rest  of 
the  tests  that  produce  a full  suite  (in  cooperation  with  the  compi  ler 
and  run-ti  me  system)  that  verifies  all  of  your  program.  And,  just 
like  having  a compiler  watching  over  your  shoulder,  wouldn't  you 
want  these  tests  hel  pi  ng  you  right  from  the  begi  nni  ng?  That's  why 
you  write  them  first,  and  run  them  automatically  with  every  build 
of  your  system.  Y our  tests  become  an  extension  of  the  safety  net 
provided  by  the  language. 

Oneofthethings  that  I've  discovered  about  the  use  of  more  and 
more  powerful  programming  languages  isthat  I am  emboldened  to 
try  more  brazen  experi  ments,  because  I know  that  the  language 
will  keep  me  from  wasting  my  time  chasing  bugs.  The  XP  test 
scheme  does  the  samethi  ng  for  your  entire  project.  Because  you 
know  your  tests  will  always  catch  any  problems  that  you  introduce 
(and  you  regularly  add  any  new  tests  as  you  think  of  them),  you 
can  make  big  changes  when  you  need  to  without  worrying  that 
you'll  throw  the  whole  project  into  complete  disarray.  This  is 
incredibly  powerful. 

Pair  programming 

Pair  programming  goes  against  the  rugged  individualism  that 
we've  been  indoctrinated  into  from  the  beginning,  through  school 
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(where  we  succeed  or  fail  on  our  own,  and  working  with  our 
neighbors  is  considered  "cheating")  and  media,  especially 
Hollywood  movies  in  which  the  hero  is  usually  fighting  against 
mind  I ess  conformity  16.  Programmers,  too,  are  considered  paragons 
of  individuality  - "cowboy  coders"  as  Larry  Constantine  I ikes  to 
say.  And  yet  XP,  which  is  itself  battling  against  conventional 
thinking,  says  that  code  should  bewritten  with  two  people  per 
workstation.  And  that  this  should  be  done  in  an  area  with  a group 
of  workstations,  without  the  barriers  that  thefaci  I ities  design 
peopi  e are  so  fond  of.  I n fact.  Beck  says  that  the  f i rst  task  of 
converting  to  XP  isto  arrive  with  screwdrivers  and  Allen  wrenches 
and  take  apart  everything  that  gets  in  the  way. 1^  (This  will  require  a 
manager  w ho  can  defi  ect  the  i re  of  the  fad  I iti  es  department.) 

Thevalueof  pair  programming  is  that  one  person  is  actually  doing 
the  coding  while  the  other  is  thinking  about  it.  The  thinker  keeps 
the  big  picture  in  mind,  not  only  the  picture  of  the  problem  at  hand, 
but  the  guidelines  of  XP.  If  two  people  are  working,  it's  less  likely 
thatoneof  them  will  getaway  with  saying,  "I  don't  want  to  write 
the  tests  first,"  for  example.  And  if  the  coder  gets  stuck,  they  can 
swap  places.  If  both  of  them  get  stuck,  their  musings  may  be 
overheard  by  someone  else  in  the  work  area  who  can  contribute. 
Working  in  pairs  keeps  things  flowing  and  on  track.  Probably  more 
important,  it  makes  programming  a lot  more  social  and  fun. 

I've  begun  using  pair  programming  during  the  exercise  periods  in 
some  of  my  seminars  and  it  seems  to  significantly  improve 
everyone's  experience. 


i^Although  this  may  be  a more  American  perspective,  the  stories  of  Hollywood 
reach  everywhere. 

i^lncluding  (especially)  the  PA  system.  I onceworked  in  a company  that  insisted  on 
broad  casti  ng  every  phone  cal  I that  arrived  for  every  executive,  and  it  constantly 
interrupted  our  productivity  (but  the  managers  couldn't  begin  to  conceive  of  stifling 
such  an  important  service  as  the  PA).  Finally,  when  no  one  was  looking  I started 
snipping  speaker  wires. 
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Why  C++  succeeds 

Part  of  the  reason  C++  has  been  so  successful  is  that  the  goal  was 
notjusttoturn  C into  an  OOP  language  (although  it  started  that 
way),  but  also  to  solve  many  other  problems  facing  developers 
today,  especially  those  who  have  large  investments  in  C. 
Traditionally,  OOP  languages  have  suffered  from  the  attitude  that 
you  should  abandon  everything  you  know  and  start  from  scratch 
with  a new  set  of  concepts  and  a new  syntax,  arguing  that  it's  better 
in  the  long  run  to  lose  all  the  old  baggagethat  comes  with 
procedural  languages.  This  may  be  true,  in  the  long  run.  But  in  the 
short  run,  a lot  of  that  baggage  was  valuable.  The  most  valuable 
elements  may  not  be  the  existing  code  base  (which,  given  adequate 
tools,  could  be  translated),  but  instead  the  existing  mind  base.  If 
you'rea  functioning  C programmer  and  must  drop  everything  you 
know  about  C in  order  to  adopt  a new  language,  you  immediately 
become  much  less  productive  for  many  months,  until  your  mind 
fits  around  the  new  paradigm.  Whereas  if  you  can  leverage  off  of 
your  existing  C knowledge  and  expand  on  it,  you  can  continueto 
be  productive  with  what  you  already  know  whilemoving  into  the 
world  of  object-oriented  programming.  As  everyone  has  his  or  her 
own  mental  model  of  programming,  this  move  is  messy  enough  as 
it  is  without  the  added  expense  of  starti  ng  with  a new  language 
model  from  square  one.  So  the  reason  for  the  success  of  C-H-,  i n a 
nutshell,  is  economic:  It  still  costs  to  moveto  OOP,  butC-H-may 
cost  less^s. 

The  goal  of  C-H- is  improved  productivity.  This  productivity  comes 
in  many  ways,  butthe  language  is  designed  to  aid  you  as  much  as 
possible,  while  hindering  you  as  littleas  possible  with  arbitrary 
rules  or  any  requirement  that  you  use  a particular  set  of  features. 
C-H- is  designed  to  be  practical;  C-H- language  design  decisions 


^^1  say"may"  because,  duetothecomplexity  of  C++,  it  might  actually  be  cheaper  to 
move  to  Java.  But  the  decision  of  which  language  to  choose  has  many  factors,  and  in 
thisbook  I'll  assume  that  you've  chosen  C++. 
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were  based  on  providing  the  maximum  benefits  to  the  programmer 
(at  least,  from  the  world  view  of  C). 

A better  C 

You  get  an  instantwin  even  if  you  conti nue to  write C code 
because  C++ has  closed  many  holes  in  the  C language  and  provides 
better  type  checking  and  compile-time  analysis.  You're  forced  to 
deci  are  fu net!  ons  so  that  the  compi  I er  can  check  thei  r use.  The  need 
for  the  preprocessor  has  virtually  been  eliminated  for  value 
substitution  and  macros,  which  removes  a set  of  difficult-to-find 
bugs.  C-H-  has  a feature  cal  led  references  that  al  lows  more 
convenient  handling  of  ad  dresses  for  function  arguments  and 
return  values.  The  handling  of  names  is  improved  through  a 
feature  cal  led  function  overloading,  which  allows  you  to  use  the  same 
namefor  different  functions.  A feature  called  namespacesalso 
i mproves  the  control  of  names.  There  are  nu  merous  smal  I er 
featu  res  that  I mprove  the  safety  of  C . 

You're  already  on  the  learning  curve 

The  problem  with  learning  a new  language  is  productivity.  No 
company  can  afford  to  suddenly  lose  a productive  software 
engineer  because  he  or  she  is  learning  a new  language.  C-H-isan 
extension  to  C,  not  a complete  new  syntax  and  programming 
model.  It  allows  you  to  conti  nue  creating  useful  code,  applying  the 
featu  res  gradually  as  you  learn  and  understand  them.  This  may  be 
one  of  the  most  I mportant  reasons  for  the  success  of  C -H-. 

In  addition,  all  of  your  existing  C codeisstill  viablein  C++,  but 
becausethe C-H- compiler  is  pickier,  you'll  often  find  hidden  C 
errors  when  recompiling  the  code  in  C-H-. 

Efficiency 

Sometimes  it  is  appropriate  to  trade  execution  speed  for 
programmer  productivity.  A financial  model,  for  example,  may  be 
useful  for  only  a short  period  of  time,  so  it's  more  i mportant  to 
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create  the  model  rapidly  than  to  execute  it  rapidly.  However,  most 
applications  require  some  degree  of  efficiency,  so  C++ always  errs 
on  the  side  of  greater  efficiency.  Because  C programmers  tend  to  be 
very  efficiency-conscious,  this  is  also  a way  to  ensure  that  they 
won't  be  abl  e to  argue  that  the  I anguage  i s too  fat  and  si  ow . A 
number  of  features  in  C-H- are  intended  to  allow  you  to  tune  for 
performance  when  the  generated  code  isn't  efficient  enough. 

Not  only  do  you  have  the  same  low-level  control  as  in  C (and  the 
ability  to  directly  write  assembly  languagewithin  a C-H- program), 
but  anecdotal  evidence  suggests  that  the  program  speed  for  an 
object-oriented  C-H- program  tends  to  be  within  +L0%of  a program 
written  in  C,  and  often  much  closeri^.  The  design  produced  for  an 
OOP  program  may  actually  be  more  efficient  than  theC 
counterpart. 


Systems  are  easier 
to  express  and  understand 

Classes  designed  to  fit  the  problem  tend  to  express  it  better.  This 
means  that  when  you  write  the  code,  you're  describing  your 
solution  in  the  terms  of  the  problem  space  ("Put  the  grommet  in  the 
bin")  rather  than  thetermsof  the  computer,  which  isthe  solution 
space  ("Set  the  bit  in  thechipthat  means  that  the  relay  will  close"). 
You  deal  with  higher-level  concepts  and  can  do  much  more  with  a 
single  line  of  code. 

The  other  benefitof  this  ease  of  expression  is  maintenance,  which 
(if  reports  can  be  bel  ieved)  takes  a huge  portion  of  the  cost  over  a 
program's  lifetime.  If  a program  is  easier  to  understand,  then  it's 
easier  to  maintain.  This  can  also  reducethecost  of  creating  and 
mai  ntai  n i ng  the  d ocu  mentati  on . 


However,  look  at  Dan  Saks'  columns  in  the  C/C++  U ser's Journal  for  some 
i mportant  i nvesti  gati  ons  i nto  C ++ 1 1 brary  performance. 
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Maximal  leverage  with  libraries 

The  fastest  way  to  create  a program  i s to  use  code  that's  al  ready 
written:  a library.  A major  goal  in  C++ is  to  make  library  use  easier. 
This  is  accomplished  by  casting  libraries  into  new  datatypes 
(cl  asses),  so  that  bri  ngi  ng  i n a I i brary  means  add  i ng  new  types  to 
the  language.  Because  the  C++compiler  takes  care  of  how  the 
library  is  used  - guaranteeing  proper  initialization  and  cleanup, 
and  ensuring  that  functions  are  cal  led  properly -you  can  focus  on 
what  you  want  the  I i brary  to  do,  not  how  you  have  to  do  it. 

Because  names  can  be  sequestered  to  portions  of  your  program  via 
C++ namespaces,  you  can  use  as  many  libraries  as  you  want 
without  the  kinds  of  name  cl  ashes  you'd  run  intowithC. 

Source-code  reuse  with  templates 

There  is  a significant  class  of  types  that  require  source-code 
modification  in  order  to  reuse  them  effectively.  The  temp/ate  feature 
in  C-H- performs  the  source  code  modification  automatically, 
making  it  an  especially  powerful  tool  for  reusing  library  code.  A 
type  that  you  design  using  templates  will  work  effortlessly  with 
many  other  types.  Templates  are  especially  nice  because  they  hide 
the  compi  exity  of  thi  s ki  nd  of  code  reuse  from  the  cl  i ent 
programmer. 

Error  handling 

Error  handling  in  C Isa  notorious  problem,  and  one  that  is  often 
ignored  -finger-crossing  isusually  involved.  If  you're  building  a 
large,  complex  program,  there's  nothing  worse  than  having  an 
error  buried  somewhere  with  no  clueasto  where  it  came  from. 
C-H-excqjtion  /iand//np  (introduced  in  this  Volume,  and  fully 
covered  in  Volume 2,  which  isdownloadablefrom 
www.BruceEckd.com)  is  a way  to  guarantee  that  an  error  is  noticed 
and  that  something  happens  as  a result. 
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Programming  in  the  iarge 

Many  traditional  languages  have  built-in  I imitations  to  program 
size  and  complexity.  BASIC,  for  example,  can  begreatfor  pulling 
together  quick  solutions  for  certain  classes  of  problems,  but  if  the 
program  gets  more  than  a few  pages  long  or  ventures  out  of  the 
normal  problem  domain  of  that  language,  it's  I ike  trying  to  swim 
through  an  ever-more  viscous  fluid.  C,too,  has  these  limitations. 
For  example,  when  a program  gets  beyond  perhaps  50,000  lines  of 
code,  name  collisions  start  to  becomea  problem  - effectively,  you 
run  out  of  function  and  variable  names.  Another  particularly  bad 
problem  isthe  little  holes  in  theC  language  - errors  buried  in  a 
large  program  can  be  extremely  difficult  to  find. 

There's  no  clear  line  that  tel  Is  you  when  your  language  is  failing 
you,  and  even  if  there  were,  you'd  ignore  it.  You  don't  say,  "My 
BASIC  program  just  got  too  big;  I'll  haveto  rewrite  it  in  C!" 

Instead,  you  try  to  shoehorn  a few  more  lines  in  to  add  that  one 
new  feature.  So  the  extra  costs  come  creeping  up  on  you. 

C-H- is  designed  to  aid  programming  in  the  iarge,  that  is,  to  erase 
those  creeping-complexity  boundaries  between  a small  program 
and  a large  one.  You  certainly  don't  need  to  use  OOP,  templates, 
namespaces,  and  exception  handling  when  you'rewriting  a hello- 
world  styleutility  program,  but  those  features  are  there  when  you 
need  them.  And  the  compiler  is  aggressive  about  ferreting  out  bug- 
producing  errors  for  smal  I and  large  programs  alike. 


Strategies  for  transition 

If  you  buy  into  OOP,  your  next  question  is  probably,  "How  can  I 
get  my  manager/  colleagues/  department/  peers  to  start  using 
objects?"  Think  about  how  you  - one  independent  programmer  - 
would  go  about  learning  to  use  a new  language  and  anew 
programming  paradigm.  You've  done  it  before.  First  comes 
education  and  examples;  then  comes  a trial  project  to  give  you  a 
feel  for  the  basics  without  doing  anything  too  confusing.  Then 
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comes  a "real  world"  project  that  actually  does  something  useful. 
Throughout  your  first  projects  you  continue  your  education  by 
reading,  asking  questions  of  experts,  and  trading  hintswith  friends. 
This  is  the  approach  many  experienced  programmers  suggest  for 
the  switch  from  C to  C++.  Switching  an  entire  company  will  of 
course  introduce  certain  group  dynamics,  but  it  will  help  at  each 
step  to  remember  how  one  person  would  do  it. 

Guidelines 

H ere  are  some  guidel  ines  to  consider  when  maki  ng  the  transition 
to  OOP  and  C++: 

1.  Training 

The  first  step  is  some  form  of  education.  Remember  the  company's 
investment  in  plain  C code,  and  try  not  to  throw  everything  into 
disarray  for  sixto  nine  months  while  everyone  puzzles  over  how 
multiple  inheritance  works.  Pick  a small  group  for  indoctrination, 
preferably  one  composed  of  people  who  are  curious,  work  well 
together,  and  can  function  as  their  own  support  network  while 
they're  learning  C++. 

An  alternative  approach  that  is  sometimes  suggested  isthe 
education  of  all  company  levels  at  once,  including  overview 
courses  for  strategic  managers  as  well  as  design  and  programming 
courses  for  project  builders.  This  is  especially  good  for  smaller 
companies  making  fundamental  shifts  in  the  way  they  do  things,  or 
atthedivision  level  of  larger  companies.  Because  the  cost  is  higher, 
however,  some  may  choose  to  start  with  project-level  training,  do  a 
pilot  project  (possibly  with  an  outside  mentor),  and  let  the  project 
team  become  the  teachers  for  the  rest  of  the  company. 

2.  Low- risk  project 

Try  a low-risk  project  first  and  allow  for  mistakes.  Once  you've 
gained  some  experience,  you  can  either  seed  other  projects  from 
members  of  this  first  team  or  use  the  team  members  as  an  OOP 
technical  support  staff.  This  first  project  may  network  right  the 
first  time,  so  it  should  not  be  mission-critical  for  the  company.  It 
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should  be  simple,  self-contained,  and  instructive;  this  means  that  it 
should  involve  creating  classes  that  will  be  meaningful  to  the  other 
programmers  in  the  company  when  they  get  their  turn  to  learn 
C-H-. 

3.  Model  from  success 

Seek  out  examples  of  good  object-oriented  design  before  starting 
from  scratch.  There's  a good  probabi  I ity  that  someone  has  solved 
your  problem  already,  and  if  they  haven't  solved  it  exactly  you  can 
probably  apply  what  you've  learned  about  abstraction  to  modify  an 
existing  design  to  fit  your  needs.  This  is  the  general  concept  of 
design  patterns,  covered  in  Volume 2. 

4.  Use  existing  ciass  iibraries 

The  primary  economic  motivation  for  switching  to  OOP  is  the  easy 
use  of  existing  code  in  the  form  of  class  libraries  (in  particular,  the 
Standard  C-h- libraries,  which  are  covered  in  depth  in  Volume  two 
of  this  book).  The  shortest  appi  i cation  development  cycle  wi  1 1 result 
when  you  don't  have  to  write  anything  but  main( ) creating  and 
using  objects  from  off-the-shelf  libraries.  However,  some  new 
programmers  don't  understand  this,  are  unaware  of  existing  class 
libraries,  or,  through  fascination  with  the  language,  desire  to  write 
classes  that  may  already  exist.  Your  success  with  OOP  and  C-H- 
will  be  optimized  if  you  make  an  effort  to  seek  out  and  reuse  other 
people's  code  early  in  the  transit!  on  process. 

5.  Don't  rewrite  existing  code  in  C+  + 

Although  compiling  your  C code  with  a C-H- compiler  usually 
produces  (sometimes  tremendous)  benefits  by  finding  problems  in 
the  old  code,  it  is  not  usually  the  best  use  of  your  time  to  take 
existing,  functional  codeand  rewrite  it  in  C-H-.  (If  you  must  turn  it 
into  objects,  you  can  "wrap"  theC  code  in  C-H- cl  asses.)  There  are 
incremental  benefits,  especially  if  the  code  is  slated  for  reuse.  But 
chances  are  you  aren't  goi  ng  to  see  the  d ramati  c i ncreases  i n 
productivity  that  you  hope  for  in  your  first  few  projects  unless  that 
project  is  a new  one.  C-h- and  OOP  shine  best  when  taking  a project 
from  concept  to  real  ity. 
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Management  obstacles 

If  you'rea  manager,  your  job  isto  acquire  resourcesfor  your  team, 
to  overcome  barriers  to  your  team's  success,  and  i n general  to  try  to 
provide  the  most  productiveand  enjoyableenvironmentsoyour 
team  is  most  I ikely  to  perform  those  miracles  that  are  always  bei  ng 
asked  of  you.  Moving  to  C-h- falls  in  all  three  of  these  categories, 
and  it  would  be  wonderful  if  it  didn't  cost  you  anything  as  well. 
Although  moving  to  C-H- may  be  cheaper  - depending  on  your 
constraints^o-  than  the  OOP  alternatives  for  a team  of  C 
programmers  (and  probably  for  programmers  in  other  procedural 
languages),  it  isn't  free,  and  there  are  obstacles  you  should  be 
aware  of  before  trying  to  sell  themoveto  C-H-within  your 
company  and  embarking  on  the  move  itself. 

Startup  costs 

The  cost  of  moving  to  C-H-is  morethan  just  the  acquisition  ofC-H- 
compilers(theGNU  C-H- compiler,  one  of  the  very  best,  is  free). 
Your  medium-  and  long-term  costs  will  be  minimized  if  you  invest 
in  training  (and  possibly  mentoring  for  your  first  project)  and  also 
if  you  identify  and  purchase  cl  ass  libraries  that  solve  your  problem 
rather  than  tryi  ng  to  bui  Id  those  I i braries  yourself.  These  are  hard- 
money  costs  that  must  be  factored  into  a realistic  proposal.  In 
addition,  there  are  the  hidden  costs  in  loss  of  productivity  while 
learning  a new  language  and  possibly  a new  programming 
environment.  Training  and  mentoring  can  certainly  minimize  these, 
but  team  members  must  overcome  their  own  struggles  to 
understand  the  new  technology.  During  this  process  they  will 
make  more  mistakes  (this  is  a feature,  because  acknowledged 
mistakes  are  the  fastest  path  to  learning)  and  be  less  productive. 
Even  then,  with  some  types  of  programming  problems,  the  right 
classes,  and  the  right  development  environment,  it's  possibleto  be 
more  productive  whileyou're  learning  C-H-(even  considering  that 


Because  of  its  productivity  improvements,  thejava  language  should  also  be 
considered  here. 
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you're  making  more  mi  stakes  and  writi  ng  fewer  iines  of  code  per 
day)  than  if  you'd  stayed  with  C. 

Performance  issues 

A common  question  is,  "Doesn't  OOP  automaticaiiy  make  my 
programs  a iot  bigger  and  siower?"  The  answer  is,  "It  depends." 
Most  traditional  OOP  languages  were  designed  with 
experimentation  and  rapid  prototyping  in  mind  rather  than  lean- 
and-mean  operation.Thus,  they  virtually  guaranteed  a significant 
increase  in  size  and  decrease  in  speed.  C++,  however,  is  designed 
with  production  programming  in  mind.  When  yourfocus ison 
rapid  prototyping,  you  can  throw  together  components  as  fast  as 
possible  while  ignoring  efficiency  issues.  If  you're  using  any  third 
party  libraries,  these  are  usually  already  optimized  by  their 
vendors;  in  any  case  it's  not  an  issue  whileyou're  in  rapid- 
development  mode.  When  you  have  a system  that  you  like,  if  it's 
small  and  fast  enough,  then  you're  done.  If  not,  you  begin  tuning 
with  a profiling  tool,  looking  first  for  speedups  that  can  be  done 
with  simple  applications  of  built-in  C-H- features.  If  that  doesn't 
help,  you  look  for  modifications  that  can  be  made  in  the  underlying 
implementation  so  no  codethat  usesa  particular  class  needsto  be 
changed.  Only  if  nothing  else  solves  the  problem  do  you  need  to 
change  the  design.  Thefactthat  performance  is  so  critical  in  that 
portion  of  the  design  is  an  indicator  that  it  must  be  part  of  the 
primary  design  criteria.  You  have  the  benefit  of  finding  this  out 
early  using  rapid  development. 

As  mentioned  earlier,  the  number  that  is  most  often  given  for  the 
differencein  size  and  speed  between  C and  C-H-is  +L0%,  and  often 
much  closer  to  par.  You  might  even  get  a significant  improvement 
in  size  and  speed  when  using  C-H- rather  than  C because  the  design 
you  make  for  C-H- could  be  quite  different  from  the  one  you'd 
make  for  C. 

The  evidence  for  size  and  speed  comparisons  between  C and  C-h- 
tendsto  be  anecdotal  and  is  likely  to  remain  so.  Regardless  of  the 
number  of  people  who  suggest  that  a company  try  the  same  project 
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using  C and  C++,  no  company  islikely  to  waste  money  that  way 
unless  it's  very  big  and  interested  in  such  research  projects.  Even 
then,  it  seems  I ike  the  money  could  be  better  spent.  A I most 
universally,  programmers  who  have  moved  from  C (or  some  other 
procedural  language)  to  C++(or  some  other  OOP  language)  have 
had  the  personal  experience  of  a great  acceleration  in  their 
programming  productivity,  and  that'sthe  most  compelling 
argument  you  can  find. 

Common  design  errors 

When  starting  your  team  into  OOP  and  C++,  programmers  will 
typically  go  through  a series  of  common  design  errors.  This  often 
happens  because  of  too  little  feed  back  from  experts  during  the 
design  and  implementation  of  early  projects,  because  no  experts 
have  been  developed  within  the  company  and  there  may  be 
resistance  to  retaining  consultants.  It's  easy  to  feel  that  you 
understand  OOP  too  early  in  the  cycle  and  go  off  on  a bad  tangent. 
Something  that's  obvious  to  someone  experienced  with  the 
language  may  bea  subject  of  great  internal  debatefor  a novice. 
Much  of  this  trauma  can  be  skipped  by  using  an  experienced 
outside  expert  for  training  and  mentoring. 

On  the  other  hand,  the  fact  that  it  is  easy  to  make  these  design 
errors  points  to  C++'s  main  drawback:  its  backward  compatibility 
with  C (of  course,  that's  also  its  main  strength).  To  accomplish  the 
feat  of  being  able  to  compile  C code,  the  language  had  to  make 
some  compromises,  which  have  resulted  in  a number  of  "dark 
corners."  These  area  reality,  and  comprise  much  of  the  learning 
curve  for  the  language.  In  this  book  and  the  subsequent  volume 
(and  in  other  books;  see  Appendix  C),  I try  to  reveal  most  of  the 
pitfalls  you  arelikely  to  encounter  when  working  with  C++.  You 
should  always  be  aware  that  there  are  some  holes  in  the  safety  net. 


Summary 

This  chapter  attempts  to  give  you  a feel  for  the  broad  issues  of 
object-oriented  programming  and  C++,  including  why  OOP  is 
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different,  and  why  C++ in  particular  is  different,  concepts  of  OOP 
methodologies,  and  finally  the  kinds  of  issues  you  will  encounter 
when  moving  your  own  company  to  OOP  and  C++. 

OOP  and  C++ may  not  be  for  everyone.  It's  important  to  evaluate 
your  own  needs  and  decide  whether  C++ will  optimally  satisfy 
those  needs,  or  if  you  might  be  better  off  with  another 
programming  system  (including  the  one  you're  currently  using).  If 
you  know  that  your  needs  will  be  very  specialized  for  the 
foreseeable  future  and  if  you  have  specific  constraints  that  may  not 
be  satisfied  by  C++,  then  you  oweittoyourself  to  investigate  the 
alternatives^!.  Even  if  you  eventually  choose  C++ as  your  language, 
you'll  at  least  understand  what  the  options  were  and  havea  clear 
vision  of  why  you  took  that  direction. 

You  know  what  a procedural  program  looks  like:  data  definitions 
and  function  calls.  To  find  the  meaning  of  such  a program  you  have 
to  work  a little,  looking  through  the  function  calls  and  low-level 
concepts  to  createa  model  in  your  mind.  This  isthe  reason  we  need 
intermediate  representations  when  designing  procedural  programs 
- by  themselves,  these  programs  tend  to  be  confusi  ng  because  the 
terms  of  expression  are  oriented  more  toward  the  computer  than  to 
the  problem  you're  solving. 

Because  C-H- adds  many  new  concepts  to  the  C language,  your 
natural  assumption  may  bethatthemain(  )in  a C-H- program  will 
be  far  more  complicated  than  for  the  equivalent  C program.  Here, 
you'll  be  pleasantly  surprised:  A well-written  C-H-program  is 
generally  far  simpler  and  much  easier  to  understand  than  the 
equivalentC  program.  What  you'll  see  are  the  definitions  of  the 
objects  that  represent  concepts  in  your  problem  space  (rather  than 
the  issues  of  the  computer  representation)  and  messages  sent  to 
those  objects  to  represent  the  activities  in  that  space.  One  of  the 


2!  In  particular,  I recommend  looking  atjava  (http://java.sun.com)  and  Python 
(http:/  / www.Python.org). 
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delights  of  object-oriented  programming  is  that,  with  a well - 
designed  program,  it's  easy  to  understand  the  code  by  reading  it. 
Usually  there's  a lot  less  code,  as  well,  because  many  of  your 
problems  will  be  solved  by  reusing  existing  library  code. 
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2:  Making  & Using  Objects 

This  chapter  will  introduce  enough  C++  syntax  and 
program  construction  concepts  to  allow  you  to  write 
and  run  some  simple  object-oriented  programs.  In  the 
subsequent  chapter  we  will  cover  the  basic  syntax  of  C 
and  C++  in  detail. 
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By  reading  this  chapter  first,  you'll  get  the  basic  flavor  of  what  it  is 
liketo  program  with  objects  in  C++,  and  you'll  also  discover  some 
of  the  reasons  for  the  enthusiasm  surrounding  this  language.  This 
should  be  enough  to  carry  you  through  Chapter  3,  which  can  be  a 
bit  exhaust!  ng  si  nee  it  contains  most  of  the  detai  Is  of  the  C 
language. 

The  user-defined  datatype,  or  c/ass,  iswhatdistinguishesC-H-from 
traditional  procedural  languages.  A class  is  a new  data  type  that 
you  or  someone  else  creates  to  solve  a particular  kind  of  problem. 
Once  a class  is  created,  anyone  can  use  it  without  knowing  the 
specifics  of  how  it  works,  or  even  how  cl  asses  are  built.  This 
chapter  treats  classes  as  if  they  are  just  another  built-in  datatype 
aval  I able  for  use  in  programs. 

Cl  asses  that  someone  else  has  created  are  typically  packaged  into  a 
I i brary . Thi  s chapter  uses  several  of  the  cl  ass  I i brari  es  that  come 
with  all  C-H- implementations.  An  especially  important  standard 
library  is  iostreams,  which  (among  other  things)  allow  you  to  read 
from  files  and  thekeyboard,  and  to  write  to  files  and  thedisplay. 
You'll  also  seethe  very  handy  stringclass,  and  the  vector  container 
from  the  Standard  C-H- Li  brary.  By  the  end  of  the  chapter,  you'll 
see  how  easy  it  isto  usea  pre-defined  library  of  classes. 

In  order  to  create  your  first  program  you  must  understand  the  tools 
used  to  build  applications. 


The  process  of  language  translation 

All  computer  languages  are  translated  from  something  that  tends 
to  be  easy  for  a human  to  understand  {source  code)  into  something 
that  is  executed  on  a computer  (mac/i/ne/nstruct/ons).  Traditionally, 
translators  fall  into  two  classes:  interpreters  and  compilers. 
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I nterpreters 

An  interpreter  translates  source  code  into  activities  (which  may 
comprisegroupsof  machine  instructions)  and  immediately 
executes  those  activities.  BASIC,  for  example,  has  been  a popular 
interpreted  language.  Traditional  BASIC  interpreters  translate  and 
execute  one  I i ne  at  a ti  me,  and  then  forget  that  the  I i ne  has  been 
translated.  This  makes  them  slow,  si  nee  they  must  re-translate  any 
repeated  code.  BASIC  has  also  been  compiled,  for  speed.  More 
modern  interpreters,  such  as  those  for  the  Python  language, 
translate  the  entire  program  into  an  intermediate  language  that  is 
then  executed  by  a much  faster  interpreter^. 

Interpreters  have  many  advantages.  The  transit!  on  from  writing 
codeto  executing  code  is  almost  immediate,  and  the  source  code  is 
always  avail  able  so  the  interpreter  can  be  much  more  specific  when 
an  error  occurs.  The  benefits  often  cited  for  i nterpreters  are  ease  of 
interaction  and  rapid  development  (but  not  necessarily  execution) 
of  programs. 

Interpreted  languages  often  have  severe  I imitations  when  building 
large  projects  (Python  seems  to  bean  exception  to  this).  The 
interpreter  (or  a reduced  version)  must  always  be  in  memory  to 
execute  the  code,  and  even  the  fastest  interpreter  may  introduce 
unacceptable  speed  restrictions.  Most  interpreters  require  that  the 
compi ete  source  code  be  brought  i nto  the  i nterpreter  al  I at  once. 
Not  only  does  this  introduce  a space  limitation,  it  can  also  cause 
more  d i ff  i cu  1 1 bu gs  i f the  I an gu  age  d oesn 't  provi  d e fad  I i ti  es  to 
localize  the  effect  of  different  pieces  of  code. 


^ The  boundary  between  compilers  and  interpreters  can  tend  to  become  a bit  fuzzy, 
especially  with  Python,  which  has  many  of  the  features  and  power  of  a compiled 
language  but  the  quick  turnaround  of  an  interpreted  language. 
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Compilers 

A compiler  translates  source  code  directly  into  assembly  language 
or  machine  instructions.  The  eventual  end  product  is  a file  or  files 
containing  machinecode.  Thisisan  involved  process,  and  usually 
takes  several  steps.  The  transition  from  writing  codeto  executing 
code  is  significantly  longer  with  a compiler. 

Depending  on  the  acumen  of  the  compiler  writer,  programs 
generated  by  a compiler  tend  to  require  much  less  space  to  run,  and 
they  run  much  more  quickly.  Although  size  and  speed  are 
probably  the  most  often  cited  reasons  for  using  a compiler,  in  many 
situations  they  aren't  the  most  important  reasons.  Some  languages 
(such  as  C)  are  designed  to  allow  pieces  of  a program  to  be 
compi  led  i ndependently.  These  pieces  are  eventual  ly  combined 
into  a final  &(ecutable  program  by  a tool  called  the //nker.  This 
process  is  called  separate  compilation. 

Separate  compilation  has  many  benefits.  A program  that,  taken  all 
at  once,  would  exceed  the  limits  of  the  compiler  or  the  compi  ling 
environment  can  decompiled  in  pieces.  Programs  can  be  built  and 
tested  one  piece  at  a time.  Once  a piece  is  working,  it  can  be  saved 
and  treated  as  a building  block.  Col  lections  of  tested  and  working 
pieces  can  be  combined  into  libraries  for  use  by  other  programmers. 
As  each  piece  is  created,  the  complexity  of  the  other  pieces  is 
hidden.  All  thesefeatures  support  the  creation  of  large  prog  rams^. 

Compiler  debugging  features  have  improved  significantly  over 
time.  Early  compilers  only  generated  machinecode,  and  the 
programmer  i nserted  pri  nt  statements  to  see  what  was  goi  ng  on. 
This  is  not  always  effective.  Modern  compilers  can  insert 
information  about  the  source  code  into  the  executable  program. 
This  information  is  used  by  powerful  source-level  debuggers  to  show 


2 Python  is  again  an  exception,  since  it  also  provides  separate  compilation. 
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exactly  what  is  happening  in  a program  by  tracing  its  progress 
through  the  source  code. 

Some  compilers  tackle  the  compilation-speed  problem  by 
performing  in-memory  compilation.  Most  compilers  work  with  files, 
reading  and  writing  them  in  each  step  of  the  compilation  process. 
In-memory  compilers  keep  the  compiler  program  in  RAM.  For 
small  programs,  this  can  seem  as  responsive  as  an  interpreter. 

The  compilation  process 

To  program  in  C and  C-H-,  you  need  to  understand  thestepsand 
tools  in  the  compilation  process.  Some  languages  (C  and  C-H-,  in 
particular)  start  compilation  by  running  a prqorocessor  on  the  source 
code.  The  preprocessor  is  a si  mple  program  that  replaces  patterns 
in  the  source  code  with  other  patterns  the  programmer  has  defined 
(using  preprocessor  directives).  Preprocessor  directives  are  used  to 
save  typing  and  to  increase  the  readability  of  the  code.  (Later  in  the 
book,  you'll  learn  how  the d esi gn  of  C-H- is  meant  to  discourage 
much  of  the  use  of  the  preprocessor,  sinceitcan  cause  subtle  bugs.) 
The  pre-processed  code  is  often  written  to  an  intermediate  file. 

Compilers  usually  do  their  work  in  two  passes.  Thefirst  pass  parses 
the  pre-processed  code.  The  compiler  breaks  the  source  code  into 
small  units  and  organizes  it  into  a structure  cal  led  atree.  Inthe 
expression  "A  + B"  the  elements  'A', and  'B'  are  leaves  on  the 
parse  tree. 

A global  optimizer  is  sometimes  used  between  thefirst  and  second 
passes  to  produce  smaller,  faster  code. 

In  the  second  pass,  the  code  generator  walks  through  the  parse  tree 
and  generates  either  assembly  language  code  or  machine  code  for 
the  nodes  of  the  tree.  If  the  code  generator  creates  assembly  code, 
the  assembler  must  then  be  run.  The  end  result  in  both  cases  is  an 
object  module  (a  file  that  typically  has  an  extension  of  .0  or  .obj).  A 
peephole  optimizer  is  sometimes  used  in  the  second  pass  to  look  for 
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pieces  of  code  containing  redundant  assembly-language 
statements. 

The  use  of  the  word  "object"  to  describe  chunks  of  machine  code  is 
an  unfortunate  artifact.  The  word  came  into  use  before  object- 
oriented  programming  was  in  general  use.  "Object"  is  used  in  the 
same  sense  as  "goal"  when  discussing  compilation,  whilein  object- 
oriented  programming  it  means  "a  thing  with  boundaries." 

The  linker  combi  nes  a 1 1st  of  object  modules  i nto  an  executable 
program  that  can  be  loaded  and  run  by  the  operating  system.  When 
a function  in  one  object  module  makes  a referenceto  a function  or 
vari  abl  e i n another  object  mod u I e,  the  I i n ker  resol  ves  these 
references;  it  makes  sure  that  all  the  external  functions  and  data 
you  claimed  existed  during  compilation  do  exist.  The  linker  also 
adds  a special  object  moduleto  perform  start-up  activities. 

Thelinker  can  search  through  special  files  called  librariesln  order  to 
resolve  all  its  references.  A library  contains  a col  lection  of  object 
modules  in  a singlefile.  A library  is  created  and  maintained  by  a 
program  called  a librarian. 

Static  type  checking 

The  compiler  performs  typechecking  during  thefi  rst  pass.  Type 
checking  tests  for  the  proper  use  of  arguments  in  functions  and 
prevents  many  kinds  of  programming  errors.  Si  nee  type  checking 
occurs  during  compilation  instead  of  when  the  program  is  running, 
it  is  cal  led  static  type  checking. 

Some  object-oriented  languages  (notably  Java)  perform  some  type 
checking  at  r\jnt\me{dynannictypechecking).  If  combined  with  static 
type  checking,  dynamic  type  checking  is  more  powerful  than  static 
type  checking  alone.  However,  it  also  adds  overhead  to  program 
execution. 

C-H-uses  static  type  checking  because  the  language  cannot  assume 
any  particular  runtime  support  for  bad  operations.  Static  type 
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checking  notifies  the  programmer  about  misuses  of  types  during 
compiiation,  and  thus  maximizes  execution  speed.  As  you  iearn 
C++,  you  wiii  see  that  most  oftheianguage  design  decisions  favor 
the  same  kind  of  high-speed,  production-oriented  programming 
theC  ianguage  is  famous  for. 

You  can  disabie  static  type  checking  in  C-H-.  You  can  aisodoyour 
own  dynamic  type  checking  - you  just  need  to  write  the  code. 


Tools  for  separate  compilation 

Separate  compiiation  is  parti  cuiariy  important  when  buiiding  iarge 
projects,  in  C and  C-H-,  a program  can  be  created  in  smaii, 
manageabie,  independentiy  tested  pieces.  The  most  fundamentai 
tooi  for  breaking  a program  up  into  pieces  istheabiiity  to  create 
named  subroutines  or  subprograms,  i n C and  C-H-,  a subprogram 
iscaiied  a function,  and  functions  arethe  pieces  of  codethat  can  be 
piaced  in  different  fiies,  enabiing  separate  compiiation.  Put  another 
way,  the  function  istheatomicunitof  code,  sinceyou  cannot  have 
part  of  a f u ncti  on  i n one  f i i e and  another  part  i n a d i fferent  f i i e;  the 
entire  function  must  bepiaced  in  a singiefiie(aithough  fiies  can 
and  do  contain  more  than  one  function). 

When  you  caii  afunction,  you  typicaiiy  pass  it  some  arguments, 
which  are  vaiues  you'd  i ike  the  function  to  work  with  during  its 
execution.  When  thefunction  isfinished,  you  typicaiiy  get  back  a 
return  value,  a vaiue  that  the  function  hands  back  to  you  as  a resuit, 
i t's  ai  so  possi  bi  e to  w ri  te  fu  ncti  ons  that  take  no  argu  ments  and 
return  no  vaiues. 

To  create  a program  with  muitipiefiies,  functions  in  onefiiemust 
access  functions  and  data  in  other  fiies.  When  compiiing  afiie,  the 
C or  C-H-compiier  must  know  about  the  functions  and  data  in  the 
other  fiies,  in  parti cuiar  their  names  and  proper  usage.  The 
compiier  ensures  that  functions  and  data  are  used  correctiy.  This 
process  of  "teiiing  the  compiier"  the  names  of  externai  functions 
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and  data  and  what  they  should  look  I ike  I seal  led  declaration.  Once 
you  declare  a function  or  variable,  the  compiler  knows  how  to 
check  to  make  sure  it  is  used  properly. 

Declarations  vs.  definitions 

It's  I mportant  to  understand  the  difference  between  declarations  and 
def/n/t/onsbecausethesetermswill  be  used  precisely  throughout 
the  book.  Essentially  all  C and  C++ programs  require  declarations. 
Before  you  can  write  your  first  program,  you  need  to  understand 
the  proper  way  to  write  a declaration. 

A declaration  introducesa  name-  an  identifier -to  the  compiler.  It 
tel  I s the  compi  I er  "Thi  s f u ncti  on  or  th i s vari  abl  e exi  sts  somew here, 
and  here  is  what  it  should  look  like."  A definition,  on  the  other 
hand,  says:  "Makethis  variable  here"  or  "Make  this  function  here." 
It  allocates  storage  for  the  name.  This  meaning  works  whether 
you're  talking  about  a variable  or  a function;  in  either  case,  at  the 
point  of  definition  the  compiler  allocates  storage.  For  a variable,  the 
compiler  determines  how  big  that  variable  is  and  causes  space  to  be 
generated  in  memory  to  hold  the  data  for  that  variable.  For  a 
function,  the  compiler  generates  code,  which  ends  up  occupying 
storage  i n memory. 

You  can  declarea  variable  or  a function  in  many  different  places, 
but  there  must  be  only  one  definition  in  C and  C++(thisis 
sometimes  cal  led  theODR:  one-definition  rule).  When  the  linker  is 
uniting  all  the  object  modules,  it  will  usually  complain  if  it  finds 
more  than  onedefinition  for  the  same  function  or  variable. 

A definition  can  also  be  a declaration.  If  the  compiler  hasn't  seen 
the  name X before  and  you  defineintx;  the  compiler  sees  the  name 
as  a deci  arati  on  and  al  I ocates  storage  for  it  al  I at  once. 

Function  declaration  syntax 

A function  declaration  in  C and  C++ gives  the  function  name,  the 
argument  types  passed  to  the  function,  and  the  return  value  of  the 
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function.  For  ©cample,  here  is  a declaration  for  a function  called 
funcl(  )that  takes  two  integer  arguments  (integers  are  denoted  in 
C/C++ with  the  keyword  int)  and  returns  an  integer: 

int  f unci ( int , int ) ; 

The  first  keyword  you  see  is  the  return  value  all  by  itself:  int  The 
arguments  are  enclosed  in  parentheses  after  the  function  name  in 
the  order  they  are  used.  The  semicolon  indicates  the  end  of  a 
statement;  inthiscase,  it  tellsthe compiler  "that'sall  - there  is  no 
function  definition  here!" 

C and  C++declarations  attempt  to  mimic  the  form  of  the  item's 
use.  For  example,  if  a is  another  integer  the  abovefunction  might 
be  used  this  way: 

a = fund  (2,3)  ; 

Sincefunc]( ) returns  an  integer,  theC  or  C++ compiler  will  check 
theuseof  funcl(  )to  makesurethatacan  accept  the  return  value 
and  that  the  arguments  are  appropriate. 

Arguments  in  function  declarations  may  have  names.  Thecompiler 
ignores  the  names  but  they  can  be  helpful  as  mnemonic  devices  for 
the  user.  For  example,  we  can  declarefuncl(  )in  a different  fash  ion 
that  has  the  same  mean!  ng: 

int  fund  (int  length,  int  width); 

A gotcha 

There  is  a significant  difference  between  C and  C++ for  functions 
with  empty  argument  lists.  In  C,  the  declaration: 

int  f unc2  ( ) ; 

means  "a  function  with  any  number  and  type  of  argument."  This 
prevents  typechecking,  so  in  C++ it  means  "a  function  with  no 
arguments." 
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Function  definitions 

Function  definitions  look  likefunction  declarations  except  that  they 
have  bodies.  A body  is  a col  lection  of  statennents  enclosed  i n braces. 
Braces  denote  the  beginning  and  ending  of  a block  of  code.  To  give 
funcl(  )a  definition  that  isan  ennpty  body  (a  body  containing  no 
code),  write: 

int  funcl(int  length,  int  width)  { } 

Notice  that  in  the  function  definition,  the  braces  replace  the 
sennicolon.  Since  braces  surround  a statennent  or  group  of 
statennents,  you  don't  need  a sennicolon.  Notice  also  that  the 
arguments  in  the  function  definition  must  have  names  if  you  want 
to  use  the  arguments  in  the  function  body  (si  nee  they  are  never 
used  here,  they  are  optional). 

Variable  declaration  syntax 

The  meaning  attributed  to  the  phrase  "variable declaration"  has 
historically  been  confusing  and  contradictory,  and  it's  important 
that  you  understand  the  correct  definition  so  you  can  read  code 
properl y.  A vari abl e deci arati  on  tel  I s the  compi  I er  w hat  a vari abl  e 
looks  like.  It  says,  "I  know  you  haven't  seen  this  name  before,  but  I 
promise  it  exists  someplace,  and  it's  a variable  of  X type." 

In  a function  declaration,  you  give  a type  (the  return  value),  the 
function  name,  the  argument  list,  and  a semicolon.  That's  enough 
for  the  compiler  to  figure  out  that  it's  a declaration  and  what  the 
function  should  look  like.  By  inference,  a vari  able  declaration  might 
be  a type  fol  I owed  by  a name.  For  exampi  e: 

int  a; 

could  declare  the  vari  able  a as  an  integer,  using  the  logic  above. 
Here's  the  conflict:  there  is  enough  information  in  the  code  above 
for  the  compi  I er  to  create  space  for  an  i nteger  cal  I ed  a,  and  that's 
what  happens.  To  resolve  this  dilemma,  a keyword  was  necessary 
forC  and  C++tosay  "This  is  only  a declaration;  it's  defined 
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elsewhere."  The  keyword  is  extern.  It  can  mean  the  definition  is 
external  to  the  file,  or  that  the  definition  occurs  later  in  the  file. 

Declaring  a variable  without  defining  it  means  using  the  extern 
keyword  before  a description  of  the  variable,  likethis: 

extern  int  a; 

extern  can  also  apply  to  function  declarations.  Forfuncl( ) it  looks 
like  this: 

extern  int  fund  (int  length,  int  width); 

This  Statement  is  equivalent  to  the  previous  funcl(  )declarations. 

Si  nee  there  is  no  function  body,  the  compiler  must  treat  it  as  a 
function  declaration  rather  than  a function  definition.  The  extern 
keyword  isthussuperfluousand  optional  for  function  declarations. 
It  is  probably  unfortunate  that  the  designers  of  C did  not  require 
theuseof  extern  for  function  declarations;  it  would  have  been  more 
consistent  and  less  confusing  (but  would  have  required  more 
typing,  which  probably  explains  the  decision). 

H ere  are  some  more  examples  of  declarations: 

//:  C02 : Declare . epp 

//  Declaration  & definition  examples 

extern  int  i;  //  Declaration  without  definition 

extern  float  f (float);  //  Function  declaration 

float  b;  //  Declaration  & definition 
float  f (float  a)  { //  Definition 

return  a + 1.0; 

} 

int  i;  //  Definition 

int  h(int  x)  { //  Declaration  & definition 
return  x + 1; 

} 

int  main  ( ) { 

b = 1.0; 
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i = 2; 
f (b)  ; 
h (i)  ; 

} III-.- 

In  the  function  declarations,  the  argument  identifiers  are  optional. 

In  the  definitions,  they  are  required  (the  identifiers  are  required 
only  in  C,  not  C++). 

Including  headers 

Most  libraries  contain  significant  numbers  of  functions  and 
variables.  To  save  work  and  ensure  consistency  when  making  the 
external  declarations  for  these  items,  C and  C++ use  a device  cal  led 
the /leader  file.  A header  file  is  a file  containing  the  external 
declarationsfor  a library;  it  conventionally  hasafilename 
extension  of 'h',  such  asheaderfile.h  (You  may  also  see  some  older 
code  using  different  extensions,  such  as  .hxxor  .hpp,  but  this  is 
becoming  rare.) 

The  programmer  who  creates  the  library  provides  the  header  file. 
To  declare  the  functions  and  external  variables  in  the  library,  the 
user  simply  includesthe  header  file.  To  include  a header  file,  use 
the  #includepreprocessor  directive.  This  tel  Is  the  preprocessor  to 
open  the  named  header  fileand  insert  its  contents  where  the 
#includestatement  appears.  A #includemay  name  a file  in  two 
ways:  in  angle  brackets  (<  >)  or  in  doublequotes. 

File  names  in  angle  brackets,  such  as: 

#include  <header> 

cause  the  preprocessor  to  search  for  thefile  in  a way  that  is 
parti  cu  I ar  to  you  r i mpl  ementati  on,  but  ty  pi  cal  I y there's  some  kind 
of  "include  search  path"  that  you  specify  in  your  environment  or 
on  the  compiler  command  line.  The  mechanism  for  setting  the 
search  path  varies  between  machines,  operating  systems,  and  C++ 
implementations,  and  may  require  some  investigation  on  your  part. 

File  names  in  double  quotes,  such  as: 
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#include  "local. h 


tell  the  preprocessor  to  search  for  the  file  in  (according  to  the 
specification)  an  "implementation-defined  way."  What  this 
typically  means  is  to  search  for  the  file  relative  to  the  current 
d i rectory.  I f the f i I e i s not  fou nd,  then  the  i ncl ude  d i recti ve  i s 
reprocessed  as  if  it  had  angle  brackets  i nstead  of  quotes. 

To  includetheiostream  header  file,  you  write: 

#include  <iostreain> 

The  preprocessor  will  find  theiostream  header  file  (often  in  a 
subdirectory  called  "include")  and  insert  it. 

Standard  C++  include  format 

As  C-H- evolved,  different  compiler  vendors  chose  different 
extensions  for  file  names.  In  addition,  various  operating  systems 
have  different  restrictions  on  filenames,  in  particular  on  name 
length.  These  issues  caused  source  code  portability  problems.  To 
smooth  over  these  rough  edges,  the  standard  uses  a format  that 
allows  file  names  longer  than  the  notorious  eight  characters  and 
eliminates  the  extension.  For  example,  instead  of  the  old  style  of 
including  iostream.h  which  looks  likethis: 

#lnclude  <iostreain . h> 

you  can  now  write: 

#include  <iostreain> 

The  transi  ator  can  i mpl  ement  the  i ncl  ude  statements  i n a way  that 
suitstheneedsof  that  particular  compiler  and  operating  system,  if 
necessary  truncating  the  name  and  adding  an  extension.  Of  course, 
you  can  also  copy  the  headers  given  you  by  your  compiler  vendor 
to  ones  without  extensions  if  you  want  to  use  this  style  before  a 
vendor  has  provided  support  for  it. 
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The  libraries  that  have  been  inherited  from  C are  still  available  with 
the  traditional  '.h'  extension.  However,  you  can  also  use  them  with 
the  more  modern  C++includestyleby  prepending  a "c"  before  the 
name.  Thus: 

#include  <stdio.h> 

#include  <stdlib.h> 

become: 

#include  <cstdio> 

#include  <cstdlib> 

And  so  on,  for  all  the  Standard  C headers.  This  provides  a nice 
distinction  to  the  reader  indicating  when  you're  using  C versus 
C++ libraries. 

The  effect  of  the  new  includeformat  is  not  identical  to  the  old: 
using  the.h  gives  you  the  older,  non-tempi  ate  version,  and 
omitting  the.h  gives  you  the  new  templatized  version.  You'll 
usually  have  problems  if  you  try  to  intermix  thetwo  forms  in  a 
single  program. 

Linking 

The  I inker  collects  object  modules  (which  often  use  file  name 
extensions  like  .0  or  .obj),  generated  by  the  compiler,  into  an 
executable  program  the  operating  system  can  load  and  run.  It  is  the 
last  phase  of  the  compilation  process. 

Linker  characteristics  vary  from  system  to  system.  I n general,  you 
just  tell  the  I inker  the  names  of  the  object  modules  and  libraries  you 
want  linked  together,  and  the  name  of  the  executable,  and  it  goes  to 
work.  Some  systems  require  you  to  invoke  the  linker  yourself.  With 
most  C -H-  packages  you  i nvoke  the  I i nker  th rough  the  C -H- 
compiler.  In  many  situations,  the  linker  is  invoked  for  you 
invisi  bly. 
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Some  older  linkers  won't  search  object  files  and  libraries  more  than 
once,  and  they  search  through  the  1 1st  you  give  them  from  left  to 
right.  This  means  that  the  order  of  object  files  and  libraries  can  be 
important.  If  you  have  a mysterious  problem  that  doesn't  show  up 
until  I ink  time,  one  possibility  is  the  order  in  which  thefilesare 
given  to  the  I inker. 

Using  libraries 

Now  that  you  know  the  basic  terminology,  you  can  understand 
how  to  use  a I i brary . To  use  a I i brary : 

1.  Include  the  library's  header  file. 

2 . U se  the  fu  ncti  ons  and  vari  abl  es  i n the  I i brary. 

3.  Link  the  library  into  the  executable  program. 

These  steps  also  apply  when  the  object  modules  aren't  combined 
into  a library.  Including  a header  fileand  linking  the  object 
modules  are  the  basic  steps  for  separate  compilation  in  both  C and 
C++. 

How  the  linker  searches  a library 

W hen  you  make  an  external  reference  to  a f u ncti  on  or  vari  abl  e i n C 
or  C++,  the  I inker,  upon  encountering  this  reference,  can  do  one  of 
two  things.  If  it  has  not  already  encountered  the  definition  for  the 
function  or  variable,  it  addsthe  identifier  to  its  list  of  "unresolved 
references."  If  thelinker  has  already  encountered  the  definition,  the 
reference  is  resolved. 

If  the  I i nker  cannot  f i nd  the  defi  ni  ti  on  i n the  I i st  of  object  mod  u I es, 
it  searches  the  I i brari  es.  Li  brari  es  have  some  sort  of  i ndexi  ng  so  the 
linker  doesn't  need  to  look  through  all  the  object  modules  in  the 
library  - it  just  looks  in  the  index.  When  the  linker  finds  a definition 
in  a library,  the  entire  object  module,  not  just  the  function 
definition,  islinked  into  the  executable  program.  Note  that  the 
whole  I i brary  isn't  I inked,  just  the  object  module  i n the  I i brary  that 
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contains  the  definition  you  want  (otherwise  programs  would  be 
unnecessarily  large).  If  you  want  to  minimize  executable  program 
size,  you  might  consider  putting  a single  function  in  each  source 
codefile  when  you  build  your  own  libraries.  This  requires  more 
editing^,  but  it  can  be  helpful  to  the  user. 

Because  the  I i nker  searches  fi  I es  i n the  order  you  give  them,  you 
can  pre-empttheuseof  a library  function  by  inserting  afilewith 
your  own  function,  using  the  same  function  name,  into  the  1 1st 
before  the  library  name  appears.  Sincethe  linker  will  resolve  any 
references  to  thisfunction  by  using  yourfunction  before  it  searches 
the  library,  yourfunction  is  used  instead  of  the  library  function. 
Notethat  this  can  also  be  a bug,  and  the  kind  of  thing  C++ 
namespaces  prevent. 

Secret  additions 

When  a C or  C++ executable  program  is  created,  certain  items  are 
secretly  linked  in.  One  of  these  is  the  startup  module,  which 
contains  initialization  routines  that  must  be  run  any  timeaC  or 
C++  program  begi  ns  to  execute.  These  routi  nes  set  up  the  stack  and 
i nitial  ize  certai  n variables  i n the  program. 

The  I i nker  always  searches  the  standard  I i brary  for  the  compi  I ed 
versions  of  any  "standard"  functions  cal  led  in  the  program. 

Because  the  standard  library  is  always  searched,  you  can  use 
anything  in  that  library  by  simply  including  the  appropriate  header 
file  in  your  program;  you  don't  have  to  tell  it  to  search  the  standard 
library.  The  iostream  functions,  for  example,  are  in  the  Standard 
C++library.  To  use  them,  you  just  includethe<iostream>header 
file. 

If  you  are  using  an  add-on  library,  you  must  explicitly  add  the 
library  nameto  the  list  of  files  handed  to  the  linker. 


3 1 would  recommend  using  Perl  or  Python  to  automate  this  task  as  part  of  your 
library-packaging  process  (seewww.Perl.org  or  www.Python.org). 
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Using  plain  C libraries 

Just  because  you  are  writing  code  in  C++,  you  are  not  prevented 
fromusingC  library  functions.  In  fact,  theentireC  library  is 
included  by  default  into  Standard  C++.  There  has  been  a 
tremendous  amount  of  work  done  for  you  in  these  functions,  so 
they  can  save  you  a I ot  of  ti  me. 

This  book  will  use  Standard  C++(and  thus  also  Standard  C)  library 
functions  when  convenient,  but  only  standard  I i brary  functions  will 
be  used,  to  ensure  the  portability  of  programs.  In  thefew  cases  in 
which  library  functions  must  be  used  that  are  not  in  theC++ 
standard,  all  attemptswill  bemadeto usePOSIX-compliant 
functions.  POSIX  is  a standard  based  on  a Unix  standardization 
effort  that  includes  functions  that  go  beyond  the  scope  of  the  C++ 
library.  You  can  generally  expect  to  find  POSIX  functions  on  Unix 
(in  particular,  Linux)  platforms,  and  often  under  DOS/  Windows. 
For  example,  if  you're  using  multithreading  you  are  better  off  using 
the  POSIX  thread  library  because  your  code  will  then  be  easier  to 
understand,  port  and  maintain  (and  the  POSIX  thread  library  will 
usual  ly  just  use  the  underlying  thread  fad  I ities  of  the  operati  ng 
system,  if  these  are  provided). 


Your  first  C++  program 

You  now  know  almost  enough  ofthe  basics  to  create  and  compile  a 
program.  The  program  will  use  the  Standard  C++iostream  classes. 
These  read  from  and  writeto  files  and  "standard"  input  and  output 
(which  normally  comes  from  and  goes  to  the  console,  but  may  be 
redirected  to  files  or  devices).  In  this  simple  program,  astream 
object  will  be  used  to  print  a message  on  the  screen. 

Using  the  iostreams  class 

To  declare  the  functions  and  external  data  in  the  iostreams  class, 
i ncl  ude  the  header  fi  I e with  the  statement 

I #include  <iostream> 
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The  first  program  uses  the  concept  of  standard  output,  which 
means"agenerai-purposepiacetosend  output."  You  wiii  see  other 
exampies  using  standard  output  in  different  ways,  but  here  it  wiii 
just  go  to  the  consoie.  The  iostream  package  automaticaiiy  defi  nes  a 
variabie  (an  object)  cai ied  coutthat  accepts  ai i data  bound  for 
standard  output. 

To  send  data  to  standard  output,  you  use  the  operator  « C 
programmers  know  this  operator  as  the  "bitwise  i eft  shift,"  which 
wiii  bedescribed  in  the  next  chapter.  Suffice  it  to  say  that  a bitwise 
ieft  shift  has  nothing  to  do  with  output.  However,  C++aiiows 
operators  to  be  overloaded.  When  you  overioad  an  operator,  you 
giveit  a new  meaning  when  that  operator  is  used  with  an  object  of 
a parti cuiar  type.  With  iostream  objects,  the  operator « means 
"send  to."  For  exampie: 

I cout  <<  "howdy!"; 

sends  the  String  "howdy!"  to  the  object  cai  ied  cout(which  is  short 
for  "consoie output"). 

That's  enough  operator  overioad ing  to  get  you  started.  Chapter  12 
covers  operator  overi  oad  i ng  i n detai  i . 

Namespaces 

As  mentioned  in  Chapter  1,  one  of  the  probiems  encountered  in  the 
C ianguageisthatyou  "run  out  of  names"  for  functions  and 
identifiers  when  your  programs  reach  a certain  size.  Of  course,  you 
don't  reaiiy  run  out  of  names;  it  does,  however,  become  harder  to 
think  of  new  ones  after  aw  hi  ie.  M ore  importantiy,  when  a program 
reaches  a certain  size  it's  typicaiiy  broken  up  into  pieces,  each  of 
which  is  buiitand  maintained  by  a different  person  or  group.  Since 
C effectiveiy  has  a si  ngie  arena  where  aii  the  identifier  and  function 
names  iive,  this  means  that  aii  thedeveiopers  must  becarefui  not  to 
accidentai  iy  use  the  same  names  in  situations  where  they  can 
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conflict.  This  rapidly  becomes  tedious,  time-wasting,  and, 
ultimately,  expensive. 

Standard  C-h- has  a mechanism  to  prevent  thiscollisi on:  the 
namespacekeyword.  Each  set  of  C-H-definitions  in  a library  or 
program  is  "wrapped"  in  a namespace,  and  if  some  other  definition 
has  an  identical  name,  but  is  in  a different  namespace,  then  there  is 
no  collision. 

Namespaces  are  a convenient  and  helpful  tool,  but  their  presence 
means  that  you  must  be  aware  of  them  before  you  can  write  any 
programs.  If  you  simply  include  a header  file  and  use  some 
functions  or  objects  from  that  header,  you'll  probably  get  strange- 
sounding  errors  when  you  try  to  compile  the  program,  to  the  effect 
that  the  compi  I er  cannot  fi  nd  any  of  the  declarati  ons  for  the  items 
that  you  just  included  in  the  header  file!  After  you  see  this  message 
afew  times  you'll  become  familiar  with  its  meaning  (which  is"You 
included  the  header  file  but  all  thedeclarationsarewithin  a 
namespace  and  you  didn't  tel  I the  compiler  that  you  wanted  to  use 
the  declarati  ons  in  that  namespace"). 

There's  a keyword  that  al  I ows  you  to  say  " I want  to  use  the 
declarations  and/  or  definitions  in  this  namespace."  This  keyword, 
appropriately  enough,  is  using  All  of  theStandard  C-h- libraries 
are  wrapped  in  a single  namespace,  which  isstd(for  "standard"). 

A s thi  s book  uses  the  standard  I i brari  es  al  most  excl  usi  vel y,  you'l  I 
see  the  foil  owing  using  cf/'rect/Vein  almost  every  program: 

using  namespace  std; 

Thi  s means  that  you  want  to  expose  al  I the  el  ements  from  the 
namespace  cal  led  std.  After  this  statement,  you  don't  have  to  worry 
that  your  particular  library  component  is  inside  a namespace,  since 
the  usi  ng  d I recti  ve  makes  that  namespace  avai  I abl  e throughout  the 
file  where  the  using  directive  was  written. 
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Exposi  ng  al  I the  elements  from  a namespace  after  someone  has 
gone  to  thetroubleto  hidethem  may  seem  a bit  counterproductive, 
and  in  fact  you  should  be  careful  about  thoughtlessly  doing  this  (as 
you'll  learn  later  in  the  book).  However,  the  using  directive 
exposes  only  those  names  for  the  current  fi  le,  so  it  is  not  quite  as 
drastic  as  it  first  sounds.  (Butthink  twice  about  doing  it  in  a header 
file  - that  is  reckless.) 

There's  a relationship  between  namespaces  and  the  way  header 
files  are  included.  Before  the  modern  header  file  inclusion  was 
standardized  (without  the  trailing  '.h',  as  in  <iostream::^,  the 
typical  way  to  include  a header  file  was  with  the'.h',  such  as 
<iostream.h>At  that  time,  namespaces  were  not  part  of  the 
language  either.  Soto  provide  backward  compatibility  with 
existing  code,  if  you  say 

I #include  <iostream . h> 

it  means 

#include  <iostream> 
using  namespace  std; 

However,  in  this  book  the  standard  include  format  will  be  used 
(without  the'.h')  and  so  the  using  directive  must  be  explicit. 

For  now,  that's  all  you  need  to  know  about  namespaces,  but  in 
Chapter  10  the  subject  is  covered  much  more  thoroughly. 

Fundamentals  of  program  structure 

A C or  C ++  program  i s a col  I ecti  on  of  vari  abl  es,  f u ncti  on 
definitions,  and  function  calls.  When  the  program  starts,  it  executes 
initialization  code  and  callsa  special  function,  "main( )"  You  put 
the  primary  code  for  the  program  here. 

As  mentioned  earlier,  a function  definition  consistsof  a return  type 
(which  must  be  specified  in  C++),  a function  name,  an  argument 
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list  in  parentheses,  and  the  function  code  contained  in  braces.  Here 
is  a sample  function  definition: 

int  function ( ) { 

//  Function  code  here  (this  is  a comment) 

} 

The  function  above  has  an  empty  argument  list  and  a body  that 
contains  only  a comment. 

There  can  be  many  sets  of  braces  within  a function  definition,  but 
there  must  always  beat  least  one  set  surrounding  thefunction 
body.  Sincemain(  )isafunction,  it  must  follow  these  rules.  In  C++, 
main(  )al  ways  has  return  type  of  int 

C and  C++ are  free  form  languages.  With  few  exceptions,  the 
compiler  ignores  newlines  and  whitespace,  so  it  must  have  some 
way  to  determi  ne  the  end  of  a statement.  Statements  are  del  i mited 
by  semicolons. 

C comments  start  with/*  and  end  with*/.  They  can  include 
newlines.  C++ uses  C-style comments  and  has  an  additional  type  of 
comment:  //.  The//  starts  a comment  that  termi  nates  with  a 
newl  i ne.  1 1 i s more  con veni  ent  than  /*  */ for  one-l  i ne  comments,  and 
is  used  extensively  in  this  book. 

"Hello,  world!" 

And  now,  finally,  thefirst  program: 

//:  C02 : Hello . cpp 
//  Saying  Hello  with  C++ 

#include  <iostreain>  //  Stream  declarations 
using  namespace  std; 

int  main  ( ) { 

cout  <<  "Hello,  World!  I am  " 

<<  8 <<  " Today!"  <<  endl; 

} ///:- 
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The  cout object  is  handed  a series  of  arguments  via  the '«' 
operators.  It  prints  out  these  arguments  in  left-to-right  order.  The 
special  iostream  function  endl  outputs  the  line  and  a newline.  With 
iostreams,  you  can  string  together  a series  of  arguments  I ike  this, 
which  makes  the  class  easy  to  use. 

In  C,  text  inside  doublequotes  is  traditionally  called  a "string." 
However,  the  Standard  C++ library  has  a powerful  cl  ass  cal  led 
stringfor  manipulating  text,  and  so  I shall  use  the  more  precise 
term  character  array  for  text  inside  double  quotes. 

The  compi  ler  creates  storage  for  character  arrays  and  stores  the 
ASCII  equivalent  for  each  character  in  this  storage.  The  compi  ler 
automatically  terminates  this  array  of  characters  with  an  extra  piece 
of  storage  containing  the  value  0 to  indicate  the  end  of  the  character 
array. 

Inside  a character  array,  you  can  insert  special  characters  by  using 
escape  sequences.  These  consist  of  a backslash  (\ ) followed  by  a 
special  code.  Forexample\  n means  newline.  Your  compiler 
manual  or  local  C guide  gives  a complete  set  of  escape  sequences; 
others  include\  t(tab),  \ \ (backslash),  and  \ b (backspace). 

Notice  that  the  statement  can  continue  over  multiple  lines,  and  that 
the  enti  re  statement  termi  nates  w i th  a semi  col  on 

Character  array  arguments  and  constant  numbers  are  mixed 
together  in  the  above  cout  statement.  Because  the  operator « is 
overloaded  with  a variety  of  meanings  when  used  with  cout  you 
can  send  cout  a variety  of  different  arguments  and  it  will  "figure 
out  what  to  do  with  the  message." 

Throughout  this  book  you 'I  I notice  that  the  fi  rst  I i ne  of  each  fi  I e wi  1 1 
be  a comment  that  starts  with  the  characters  that  start  a comment 
(typically//),  followed  by  a colon,  and  thelast  line  of  the  listing  will 
end  with  a comment  foil  owed  by  7:~'.  This  is  a technique  I use  to 
allow  easy  extraction  of  information  from  codefiles  (the  program 
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to  do  this  can  be  found  in  volume  two  of  this  book,  at 
WWW. BruceEckd.com).  The  flr^Wneal^  has  the  name  and  location 
of  the  f i I e,  so  it  can  be  referred  to  i n text  and  i n other  fi  I es,  and  so 
you  can  easily  locateit  in  the  source  code  for  this  book  (which  is 
down  load  able  from  www.BruceEckd.com). 

Running  the  compiler 

After  downloading  and  unpacking  the  book's  source  code,  find  the 
program  in  the  subdirectory  CO  2 I nvokethe  compiler  with 
H el  I oxppas  the  argu  ment.  For  si  mpl  e,  one-f  i I e programs  I i ke  thi  s 
one,  most  compilers  will  takeyou  all  theway  through  the  process. 
For  example,  to  use  the  GNU  C-H-compiler  (which  is  freely 
available  on  the  I nternet),  you  write: 

I g++  Hello. cpp 

Other  compi  lers  will  have  a si  mi  lar  syntax;  consult  your  compi  ler's 
documentation  for  details. 


More  about  iostreams 

So  far  you  have  seen  only  the  most  rudi  mentary  aspect  of  the 
iostreams  cl  ass.  The  output  formatting  avail  able  with  iostreams 
also  in  eludes  features  such  as  number  formatting  in  decimal,  octal, 
and  hexadeci  mal . H ere's  another  example  of  the  use  of  iostreams: 

//:  C02 : Stream2 . cpp 
//  More  streams  features 
#include  <iostream> 
using  namespace  std; 

int  main  ( ) { 

//  Specifying  formats  with  manipulators: 
cout  <<  "a  number  in  decimal:  " 

<<  dec  <<  15  <<  endl; 

cout  <<  "in  octal:  " <<  oct  <<  15  <<  endl; 
cout  <<  "in  hex:  " <<  hex  <<  15  <<  endl; 
cout  <<  "a  floating-point  number:  " 
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<<  3.14159  <<  endl; 

cout  <<  "non-printing  char  (escape)  : " 

<<  char  (27)  <<  endl; 

} ///:- 

This  ©cample  shows  the  iostreams  class  printing  numbers  in 
decimal,  octal,  and  hexadecimal  using  iostream  manipulators  (which 
don't  pri  nt  anythi  ng,  but  change  the  state  of  the  output  stream). 
The  formatti  ng  of  floating-point  numbers  is  determined 
automatically  by  the  compiler.  In  addition,  any  character  can  be 
sent  to  a stream  object  using  a cast  to  a char  (a  char  is  a data  type 
that  holds  singlecharacters).  This  cast  looks  I ike  a function  call: 
char( ) along  with  the  character's  A SC  1 1 value.  In  the  program 
above,  thechar(27)sends  an  "escape"  to  cout 

Character  array  concatenation 

A n i mportant  featu re  of  the  C preprocessor  i s character  array 
concatenat/on.Thisfeatureisused  in  someof  the  examples  in  this 
book.  If  two  quoted  character  arrays  are  adjacent,  and  no 
punctuation  is  between  them,  the  compiler  will  paste  the  character 
arrays  together  i nto  a single  character  array.  This  is  particularly 
useful  when  code  listings  have  width  restrictions: 

//:  C02 : Concat . cpp 
//  Character  array  Concatenation 
#include  <iostream> 
using  namespace  std; 

int  main  ( ) { 

cout  <<  "This  is  far  too  long  to  put  on  a " 

"single  line  but  it  can  be  broken  up  with  " 

"no  ill  effectsXnas  long  as  there  is  no  " 

"punctuation  separating  adjacent  character  " 

"arrays . \n" ; 

} ///:- 

At  fi  rst,  the  code  above  can  I ook  I i ke  an  error  because  there's  no 
familiar  semicolon  at  the  end  of  each  line.  Remember  that  C and 
C-H-arefree-form  languages,  and  although  you'll  usually  see  a 
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semicolon  at  the  end  of  each  line,  the  actual  requirement  is  for  a 
semicolon  at  the  end  of  each  statement,  and  it's  possible  for  a 
statement  to  conti nue  over  several  I i nes. 

Reading  input 

The  iostreams  classes  provide  the  ability  to  read  input.  The  object 
used  for  standard  input  iscin  (for  "console  input"),  cin  normally 
expects  in  put  from  the  console,  butthis  input  can  be  redirected 
from  other  sources.  An  example  of  redirection  is  shown  later  in  this 
chapter. 

The  iostreams  operator  used  with  cin  is».  This  operator  waits  for 
the  same  kind  of  input  as  its  argument.  For  example,  if  you  give  it 
an  integer  argument,  it  waits  for  an  integer  from  the  console.  Here's 
an  example: 

//:  C02 : Numconv . cpp 

//  Converts  decimal  to  octal  and  hex 
#include  <iostream> 
using  namespace  std; 

int  main  ( ) { 

int  number; 

cout  <<  "Enter  a decimal  number: 
cin  >>  number; 

cout  <<  "value  in  octal  = 0" 

<<  oct  <<  number  <<  endl; 
cout  <<  "value  in  hex  = Ox" 

<<  hex  <<  number  <<  endl; 

} ///:- 

This  program  converts  a number  typed  in  by  the  user  into  octal  and 
hexadecimal  representations. 

Calling  other  programs 

While  the  typical  way  to  usea  program  that  readsfrom  standard 
input  and  writes  to  standard  output  is  within  a Unix  shell  script  or 
DOS  batch  file,  any  program  can  be  called  from  insidea  C or  C++ 
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program  using  the  Standard  C system(  )function,  which  is 
declared  in  the  header  file  <cstdlib> 

//:  C02 : CallHello . cpp 
//  Call  another  program 

#include  <cstdlib>  //  Declare  "systemO" 
using  namespace  std; 

int  main  ( ) { 

system ( "Hello" ) ; 

} ///:- 

To  usethesystem(  )function,  you  giveitacharacter  array  that  you 
would  normally  type  at  the  operating  system  command  prompt. 
Thiscan  also  includecommand-line  arguments,  and  the  character 
array  can  be  one  that  you  fabricate  at  run  time(instead  of  just  using 
a static  character  array  as  shown  above).  The  command  executes 
and  control  returnsto  the  program. 

This  program  showsyou  how  easy  it  isto  use  plain  C library 
functionsin  C++;  just  include  the  header  file  and  call  the  function. 
This  upward  compatibility  from  C to  C++ is  a big  advantage  if  you 
are  I earning  the  language  starting  from  a background  in  C. 


Introducing  strings 

Whilea  character  array  can  be  fairly  useful,  it  isquite  limited.  It's 
simply  a group  of  characters  i n memory,  but  if  you  want  to  do 
anything  with  ityou  must  manage  all  the  little  details.  For  example, 
thesizeof  a quoted  character  array  is  fixed  at  compile  time.  If  you 
have  a character  array  and  you  want  to  add  some  more  characters 
to  it,  you'll  need  to  understand  quitea  lot  (including  dynamic 
memory  management,  character  array  copying,  and  concatenation) 
before  you  can  get  your  wish.  This  is  exactly  the  kind  of  thing  we'd 
I ike  to  have  an  object  do  for  us. 

The  Standard  C++stringclass  is  designed  to  take  care  of  (and  hide) 
all  the  low-level  manipulationsof  character  arrays  that  were 
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previously  required  oftheC  programmer.  These  manipulations 
have  been  a constant  source  of  ti  me-wasting  and  errors  si  nee  the 
inception  of  the  C language.  So,  although  an  entire  chapter  is 
devoted  to  the  stringclass  in  Volume  2 of  this  book,  thestringisso 
important  and  it  makes  life  so  much  easier  that  it  will  be 
introduced  here  and  used  in  much  of  the  early  part  of  the  book. 

To  use stri you  i ncl ude  the  C ++  header  fi  I e <stri ng>  The stri ng 
class  is  in  the  namespace  std  so  a using  directive  is  necessary. 
Because  of  operator  overloading,  the  syntax  for  using  string  is 
quite  intuitive: 


//:  C02 : HelloStrings . epp 

//  The  basics  of  the  Standard  C++  string  class 
#include  <string> 

#include  <iostream> 
using  namespace  std; 

int  main  ( ) { 

string  si,  s2;  //  Empty  strings 

string  s3  = "Hello,  World.";  //  Initialized 

string  s4("I  am");  //  Also  initialized 

s2  = "Today";  //  Assigning  to  a string 

si  = s3  + " " + s4;  //  Combining  strings 

si  +=  " 8 ";  //  Appending  to  a string 

cout  <<  si  + s2  + "!"  <<  endl; 

} ///:- 

The  first  two  String,  si  and  s2,  start  out  empty,  whiles3and  s4 
show  two  equivalent  ways  to  initializestringobjectsfrom  character 
arrays  (you  can  just  as  easily  initializestringobjectsfrom  other 
string  objects). 

You  can  assign  to  any  stringobject  using  '='.  This  replaces  the 
previous  contents  of  the  string  with  whatever  Ison  the  right-hand 
side,  and  you  don't  have  to  worry  about  what  happens  to  the 
previous  contents  - that's  handled  automatically  for  you.  To 
combine  string  you  simply  usethe'+'  operator,  which  also  allows 
you  to  combine  character  arrays  with  string.  If  you  want  to 
append  either  a stringor  a character  array  to  another  string  you 
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can  use  the  operator  Finally,  note  that  iostreams  already  know 
what  to  do  with  string,  so  you  can  just  send  a string  (or  an 
expression  that  produces  a string  which  happens  with  si  + s2  + 
"!")  directly  to  cout in  order  to  print  it. 


Reading  and  writing  fiies 

In  C,  the  process  of  opening  and  manipulating  files  requires  a lot  of 
language  background  to  prepare  you  for  the  complexity  of  the 
operations.  However,  theC-H-iostream  library  provides  a simple 
way  to  man!  pul  ate  files,  and  sothisfunctionality  can  be  introduced 
much  earlier  than  it  would  be  in  C. 

To  open  files  for  reading  and  writing,  you  must  include<fstream> 
Although  this  will  automatically  include  <iostream5»  it'sgenerally 
prudent  to  explicitly  include<iostream>if  you're  planning  to  use 
cin,  cout  etc. 

To  open  a file  for  reading,  you  create  an  if  stream  object,  which  then 
behaves  I i ke  ci  n.  To  open  a fi  le  for  writ!  ng,  you  create  an  of  stream 
object,  which  then  behaves  I i ke  cout  Once  you've  opened  the  file, 
you  can  read  from  it  or  write  to  it  just  as  you  would  with  any  other 
iostream  object.  It'sthat  simple  (which  is,  of  course,  the  whole 
point). 

Oneofthe  most  useful  functions  in  the  iostream  library  is 
getline( ) which  allows  you  to  read  one  line  (terminated  by  a 
newl  i ne)  i nto  a stri  ng  object^.  The  f i rst  argu  ment  i s the  if  stream 
object  you 're  reading  from  and  the  second  argument  is  the  string 
object.  When  the  function  call  isfinished,  the  stringobject  will 
contai  n the  I i ne. 


^ There  are  actually  a number  of  variants  of  get! ine( ) which  will  be  discussed 
thoroughly  in  the  iostreams  chapter  in  Volume  2. 
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Here's  a simple  ©cample,  which  copies  the  contents  of  one  file  into 
another: 

//:  C02 : Scopy . cpp 

//  Copy  one  file  to  another,  a line  at  a time 
#include  <string> 

#include  <fstream> 
using  namespace  std; 

int  main  ( ) { 

ifstream  in ( "Scopy . cpp" ) ; //  Open  for  reading 
of stream  out ( "Scopy2 . cpp" ) ; //  Open  for  writing 

string  s; 

while (getline (in,  s) ) II  Discards  newline  char 
out  <<  s <<  "\n";  //  ...  must  add  it  back 
} III-.- 

To  open  the  files,  you  just  hand  theifstreamand  of  stream  objects 
thefi  le  names  you  want  to  create,  as  seen  above. 

There  is  a new  concept  introduced  here,  which  isthewhileloop. 
Although  this  will  be  explained  in  detail  in  the  next  chapter,  the 
basic  idea  is  that  the  expression  in  parentheses  following  the  while 
controls  the  execution  of  the  subsequent  statement  (which  can  also 
be  multi  pie  statements,  wrapped  inside  curly  braces).  As  long  as 
the  express! on  in  parentheses  (i  n this  case,  get! ine(in,s)  produces 
a"true"  result,  then  the  statement  control  led  by  thewhilewill 
continue  to  execute.  It  turns  out  that  getline(  )will  return  a value 
that  can  be  interpreted  as  "true"  if  another  line  has  been  read 
successfully,  and  "false"  upon  reaching  the  end  of  the  input.  Thus, 
the  above  while  loop  reads  every  line  in  the  input  file  and  sends 
each  I i ne  to  the  output  fi  I e. 

getline(  )reads  in  the  characters  of  each  line  until  it  discovers  a 
newline  (the  termination  character  can  be  changed,  but  that  won't 
bean  issue  until  theiostreamschapter  in  Volume  2).  However,  it 
discardsthe  newline  and  doesn't  store  it  in  the  resulting  string 
object.  Thus,  if  we  want  the  copied  file  to  look  just  I ike  the  source 
file,  we  must  add  the  new  line  back  in,  as  shown. 
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A nother  i nteresti  ng  ©campl  e i s to  copy  the  enti  re  fi  I e i nto  a si  ngl  e 
string  object: 


//:  C02 : Fillstring . cpp 

//  Read  an  entire  file  into  a single  string 
#include  <string> 

#include  <iostream> 

#include  <fstream> 
using  namespace  std; 

int  main  ( ) { 

ifstream  in ( "Fillstring . cpp" ) ; 
string  s,  line; 
while (getline (in,  line)) 
s +=  line  + "\n"; 
cout  <<  s; 

} ///:- 

Because  of  the  dynamic  nature  of  string,  you  don't  have  to  worry 
about  how  much  storage  to  allocate  for  a string  you  can  just  keep 
adding  things  and  thestringwill  keep  expanding  to  hold  whatever 
you  put  into  it. 

O ne  of  the  ni  ce  thi  ngs  about  putti  ng  an  enti  re  f i I e i nto  a stri  ng  i s 
that  the  string  cl  ass  has  many  functions  for  searching  and 
manipulation  that  would  then  allow  you  to  modify  the  file  as  a 
single  string.  However,  this  has  its  limitations.  For  one  thing,  it  is 
often  conveni  ent  to  treat  a fi  I e as  a col  I ecti  on  of  I i nes  i nstead  of  just 
a big  blob  of  text.  For  example,  if  you  want  to  add  line  numbering 
it's  much  easier  if  you  have  each  lineas  a separate  stri ngobject.  To 
accomplish  this,  we'll  need  another  approach. 


I ntroducing  vector 

With  string,  wecan  fill  up  a stri  ngobject  without  knowing  how 
much  storagewe'regoing  to  need.  The  problem  with  reading  lines 
from  afileinto  individual  stringobjectsisthatyou  don't  know  up 
front  how  many  string  you're  going  to  need  - you  only  know  after 
you've  read  theentirefile.  To  solve  this  problem,  we  need  some 
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sort  of  holder  that  will  automatically  expand  to  contain  as  many 
stringobjectsas  wecareto  put  into  it. 

In  fact,  why  limit  ourselves  to  holding  string  objects?  It  turns  out 
that  this  kind  of  problem  - not  knowing  how  many  of  something 
you  have  whileyou're  writing  a program  - happens  a lot.  And  this 
"container"  object  sounds  like  it  would  be  more  useful  ifitwould 
hold  any  kind  of  object  at  all!  Fortunately,  the  Standard  C-H-Library 
has  a ready-made  solution:  the  standard  container  classes.  The 
container  cl  asses  are  one  of  the  real  powerhouses  of  Standard  C-H-. 

There  is  often  a bit  of  confusion  between  the  contai  ners  and 
algorithms  in  theStandard  C-H-Library,  and  the  entity  known  as 
the  STL . The  Standard  Tempi  ate  L i brary  was  the  name  A I ex 
Stepanov  (who  was  working  at  Hewlett-Packard  at  the  time)  used 
when  he  presented  his  I i brary  to  the  C-H-Standards  Committee  at 
the  meeting  in  San  Diego,  California  in  Spring  1994.  The  name 
stuck,  especially  after  HP  decided  to  make  it  avail  able  for  public 
downloads.  Meanwhile,  the  committee  integrated  itintothe 
Standard  C-H-Library,  making  a largenumber  of  changes.  STL's 
development  continues  at  Silicon  Graphics(SGI;  see 
http://www.5gi. com/Technology/STL).TheSG\  STL  diverges  from  the 
Standard  C-H-Library  on  many  subtle  points.  So  although  it's  a 
popular  misconception,  the C-H- Standard  does  not  "include"  the 
STL.  It  can  be  a bit  confusing  si  nee  the  contai  ners  and  algorithms  in 
theStandard  C-H-Library  have  the  same  root  (and  usually  the  same 
names)  as  the  SGI  STL.  In  this  book,  I will  say  "TheStandard  C-H- 
Library"  or  "TheStandard  Library  containers,"  or  something 
similar  and  will  avoid  the  term  "STL." 

Even  though  the  implementation  of  theStandard  C-H-Library 
contai  ners  and  algorithms  uses  some  advanced  concepts  and  the 
full  coverage  takes  two  large  chapters  in  Volume  2 of  this  book,  this 
library  can  also  be  potent  without  knowing  a lot  about  it.  It's  so 
useful  that  the  most  basic  of  the  standard  containers,  the  vector  is 
introduced  in  this  early  chapter  and  used  throughout  the  book. 
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You'll  find  that  you  can  do  a trennendous  amount  just  by  using  the 
basics  of  vectorand  not  worry i ng  about  the  underlyi  ng 
implementation  (again,  an  important  goal  of  OOP).  Si  nee  you'll 
learn  much  more  about  this  and  the  other  containers  when  you 
reach  the  Standard  Library  chapters  in  Volume  2,  it  seems 
forgivable  if  the  programs  that  use  vectori  n the  early  portion  of  the 
book  aren't  exactly  what  an  experienced  C++ programmer  would 
do.  You'll  find  that  in  most  cases,  the  usage  shown  here  is 
adequate. 

Thevectorclass \satemplate,  which  meansthat  it  can  be  efficiently 
appi  ied  to  different  types.  That  is,  we  can  create  a vectorof  shapes, 
a vectorof  cats,  a vectorof  string,  etc.  Basically,  with  atemplate 
you  can  create  a "class  of  anything."  Totell  the  compiler  what  it  is 
that  the  cl  ass  will  work  with  (in  thiscase,  whatthevectorwill 
hold),  you  put  the  name  of  the  desired  typein  "angle  brackets," 
which  means 'c'  and  '>'.  So  a vectorof  stringwould  be  denoted 
vector<string>When  you  do  this,  you  end  up  with  a customized 
vector  that  will  hold  only  stringobjects,  and  you'll  get  an  error 
message  from  the  compiler  if  you  try  to  put  anything  else  into  it. 

Since  vectorexpresses  the  concept  of  a "contai  ner,"  there  must  be  a 
way  to  put  thi  ngs  i nto  the  contai  ner  and  get  thi  ngs  back  out  of  the 
container.  To  add  a brand-new  element  on  the  end  of  a vector,  you 
use  the  member  function  push_back(  )j(  Remember  that,  si  nee  it's  a 
member  function,  you  usea to  call  it  for  a particular  object.)  The 
reason  the  name  of  this  member  function  might  seem  a bit  verbose 
- push_back(  instead  of  something  simpler  I ike  "put"  - is  because 
there  are  other  containers  and  other  member  functions  for  putting 
new  elements  into  containers.  For  example,  there  is  an  insert( ) 
member  function  to  put  something  in  the  middle  of  a container, 
vectorsupportsthis  but  its  use  is  more  complicated  and  we  won't 
need  to  explore  it  until  Volume  2 of  the  book.  There's  also  a 
push_front(  Knot  part  of  vectoi)  to  put  things  at  the  beginning. 
There  are  many  more  member  functions  i n vectorand  many  more 


114 


Thinking  in  C+  + 


www.BruceEckel.com 


containers  in  the  standard  C++ Library,  but  you'll  be  surprised  at 
how  much  you  can  do  just  knowing  about  a few  simple  features. 

So  you  can  put  new  elements  into  a vectorwith  push_back( ) but 
how  do  you  get  these  elements  back  out  again?  This  solution  is 
more  cl  ever  and  elegant  - operator  overloading  is  used  to  make  the 
vector  look  I ike  an  array.  The  array  (which  will  be  described  more 
fully  in  the  next  chapter)  is  a data  type  that  is  available  in  virtually 
every  programming  language  so  you  should  already  be  somewhat 
familiarwith  it.  Arrays  are  aggregates,  which  mean  they  consist  of  a 
nu mber  of  el  ements  cl  u mped  together.  The  d I sti  ngu i shi  ng 
characteristic  of  an  array  is  that  these  el  ements  are  the  same  size 
and  are  arranged  to  be  one  right  after  the  other.  M ost  i mportantly, 
these  el  ements  can  be  selected  by  "indexing,"  which  means  you  can 
say  "I  want  element  number  n"  and  that  element  will  be  produced, 
usually  quickly.  Although  there  are  exceptions  in  programming 
languages,  the  indexing  is  normally  achieved  using  square 
brackets,  so  if  you  have  an  array  a and  you  want  to  produce 
element  five,  you  say  a[4]  (note that  indexing  always  starts  at  zero). 

This  very  compact  and  powerful  indexing  notation  is  incorporated 
into  the  vector  using  operator  overloading,  just  like'«'  and  '»' 
were  incorporated  into  iostreams.  Again,  you  don't  need  to  know 
how  the  overloading  was  implemented  - that's  saved  for  a later 
chapter-  but  it's  helpful  if  you're  aware  that  there's  some  magic 
going  on  under  the  covers  in  order  to  makethe[  ]work  with 
vector. 

With  that  in  mind,  you  can  now  seea  program  that  uses  vector.  To 
use  a vector,  you  i ncl  ude  the  header  fi  le  <vector> 

//:  C02 : Fillvector . cpp 

//  Copy  an  entire  file  into  a vector  of  string 
#include  <string> 

#include  <iostream> 

#include  <fstream> 

#include  <vector> 
using  namespace  std; 
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int  main  ( ) { 

vector<string>  v; 

ifstream  in ( "Fillvector . cpp" ) ; 

string  line; 

while (getline (in,  line)) 

V . push_back ( line ) ; //  Add  the  line  to  the  end 
//  Add  line  numbers: 
for(int  i = 0;  i < v.sizeO;  i++) 
cout  <<  i <<  " <<  v[i]  <<  endl; 

} ///:- 

Much  of  this  program  is  similar  to  the  previous  one;  a file  is  opened 
and  lines  are  read  into  string  objects  one  at  a time.  However,  these 
stringobjects  are  pushed  onto  the  back  of  the  vector  v Once  the 
w h i I e I oop  comp  I etes,  the  enti  re  f i I e i s resi  d ent  i n memory,  i nsi  d e 

V. 

The  next  statement  i n the  program  is  cal  led  a for  I oop.  It  is  similar 
to  a while  I oop  except  that  it  adds  some  extra  control.  After  the  for, 
there  is  a "control  expression"  inside  of  parentheses,  just  I ike  the 
whileloop.  However,  this  control  expression  is  in  three  parts:  a 
part  which  initializes,  onethatteststo  see  if  we  should  exit  the 
loop,  and  one  that  changes  something,  typically  to  step  through  a 
sequence  of  items.  This  program  shows  the  for  I oop  in  the  way 
you'll  see  it  most  commonly  used:  the  initialization  part  inti  =0 
creates  an  integer  i to  use  as  a loop  counter  and  gives  it  an  initial 
valueof  zero.  The  testing  portion  says  that  to  stay  in  the  loop,  i 
should  be  I ess  than  the  number  of  elements  in  the  vector  v (This  is 
produced  using  the  member  function  size( ), which  I just  sort  of 
slipped  in  here,  but  you  must  admit  it  has  a fairly  obvious 
meaning.)  The  final  portion  uses  a shorthand  forC  and  C++,  the 
"auto-increment"  operator,  to  add  one  to  the  value  of  i.  Effectively, 
i ++ says  "get  the  value  of  i,  add  oneto  it,  and  put  the  result  back 
into  i.  Thus,  the  total  effect  of  the  for  I oop  is  to  take  a variable!  and 
march  it  through  the  values  from  zero  to  one  less  than  the  size  of 
the  vector  For  each  valueof  i,  the  cout  statement  is  executed  and 
this  builds  a I inethat  consists  of  the  value  of  i (magically  converted 
to  a character  array  by  cout),  a colon  and  a space,  the  line  from  the 
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file,  and  a newline  provided  by  endl.  When  you  compileand  run  it 
you'll  see  the  effect  is  to  add  line  numbers  to  the  file. 

Becauseof  the  way  that  the '»'  operator  works  with  iostreams, 
you  can  easily  modify  the  program  above  so  that  it  breaks  up  the 
input  into  whitespace-separated  words  instead  of  lines: 

//:  C02 : GetWords . cpp 

//  Break  a file  into  whitespace-separated  words 
#include  <string> 

#include  <iostream> 

#include  <fstream> 

#include  <vector> 
using  namespace  std; 

int  main  ( ) { 

vector<string>  words; 
if stream  in ( "GetWords . cpp" ) ; 
string  word; 
while (in  >>  word) 

words . push_back (word)  ; 
for(int  i = 0;  i < words . size () ; iff) 
cout  <<  words [i]  <<  endl; 

} ///:- 

The  expression 

while (in  >>  word) 

is  what  gets  the  input  one"word"  atatime,  and  when  this 
expression  evaluates  to  "false"  it  means  the  end  ofthefile  has  been 
reached.  Of  course,  delimiting  words  by  whitespace  is  quite  crude, 
but  it  makes  for  a si  mple  exampi  e.  Later  i n the  book  you'l  I see  more 
sophisticated  examples  that  let  you  break  up  inputjust  about  any 
way  you'd  like. 

To  demonstrate  how  easy  it  is  to  use  a vector  with  any  type,  here's 
an  exampi  e that  creates  a vector<i  nt> 

//:  C02 : Intvector . cpp 

//  Creating  a vector  that  holds  integers 
#include  <iostream> 
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#include  <vector> 
using  namespace  std; 


int  main  ( ) { 

vector<int>  v; 

for(int  i = 0;  i < 10;  i++) 

V . push_back ( i ) ; 

for(int  i = 0;  i < v.sizeO;  i++) 
cout  <<  v[i]  <<  ", 
cout  <<  endl; 

for(int  i = 0;  i < v.sizeO;  i++) 
v[i]  = v[i]  * 10;  //  Assignment 
for(int  i = 0;  i < v.sizeO;  i++) 
cout  <<  v[i]  <<  ",  "; 

cout  <<  endl; 

} ///:- 

To  create  a vectorthat  holds  a different  type,  you  just  put  that  type 
in  as  the  tempi  ate  argument  (the  argument  in  angle  brackets). 
Templates  and  well-designed  template  libraries  are  intended  to  be 
exactly  this  easy  to  use. 

This  example  goes  on  to  demonstrate  another  essential  feature  of 
vector.  In  the  expression 

v[i]  = v[i]  * 10; 

you  can  see  that  the  vector  is  not  limited  to  only  putting  things  in 
and  getting  things  out.  You  also  have  the  ability  to  assign  (and  thus 
to  change)  to  any  element  of  a vector  also  through  the  use  of  the 
square-brackets  indexing  operator.  This  means  that  vectoris  a 
general-purpose,  flexible  "scratch pad"  for  working  with  collections 
of  objects,  and  wewill  definitely  makeuseof  it  in  coming  chapters. 


Summary 

The  intent  of  this  chapter  is  to  show  you  how  easy  object-oriented 
programming  can  be  - /fsomeone  else  has  goneto  the  work  of 
defining  the  objects  for  you.  In  that  case,  you  include  a header  file, 
create  the  objects,  and  send  messages  to  them.  If  the  types  you  are 
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using  are  powerful  and  well-designed,  then  you  won't  haveto  do 
much  work  and  your  resulting  program  will  also  be  powerful. 


In  the  process  of  showing  the  ease  of  OOP  when  using  library 
classes,  this  chapter  also  introduced  some  of  the  most  basic  and 
useful  types  in  the  Standard  C-H- library:  the  family  of  iostreams  (in 
particular,  those  that  read  from  and  write  to  the  console  and  files), 
the  string  cl  ass,  and  the  vectortemp  I ate.  You've  seen  how 
straightforward  it  is  to  use  these  and  can  now  probably  imagine 
many  things  you  can  accomplish  with  them,  but  there's  actually  a 
lot  morethat  they're  capable  of^.  Even  though  we'll  only  be  using  a 
I i mi  ted  su  bset  of  the  f u ncti  onal  i ty  of  these  tool  s i n the  earl  y part  of 
the  book,  they  nonetheless  provide  a large  step  up  from  the 
primitiveness  of  learning  a low-level  language  I ikeC.  and  while 
learning  the  low-level  aspects  of  C is  educational,  it'salsotime 
consuming.  In  the  end,  you'll  be  much  more  productive  if  you've 
got  objects  to  manage  the  low-level  issues.  After  all,  the  whole  po/nt 
of  OOP  is  to  hidethedetailssoyou  can  "paint  with  a bigger 
brush." 

However,  as  high-level  as  OOP  tries  to  be,  there  are  some 
fundamental  aspects  of  C that  you  can't  avoid  knowing,  and  these 
will  be  covered  i n the  next  chapter. 


Exercises 

Solutions  to  selected  exercises  can  be  found  in  the  electronic  document  TheThinking  in  C++ Annotated 
Solution  Guide,  aval  I able  for  a small  fee  from  http://www.BruceEckel.com 

1.  Modify  Hell  oxppso  that  it  prints  out  your  name  and  age 
(or  shoe  size,  or  your  dog's  age,  if  that  makes  you  feel 
better).  Compi  le  and  run  the  program. 


5 If  you're  particularly  eager  to  see  all  the  things  that  can  bedonewith  these  and 
other  Standard  library  components,  seeVolume2  of  this  book  at 
www.BruceEckei.com,  and  aisowww.dinkumware.com. 
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2.  Using  Stream 2.cp panel  Numconv.cppas  guidelines, 
create  a program  that  asks  for  the  rad  i us  of  a ci  rcl  e and 
pri  nts  the  area  of  that  ci  rcl  e.  Y ou  can  just  use  the 
operator  to  square  the  rad  i us.  Do  not  try  to  pri  nt  out  the 
value  as  octal  or  hex  (these  only  work  with  integral 
types). 

3.  Create  a program  that  opens  a file  and  counts  the 
whitespace-separated  words  in  that  file. 

4 . C reate  a program  that  cou  nts  the  occu rrence  of  a 
particular  word  in  afile(usethestringclass'  operator 
'=='  to  find  the  word). 

5.  ChangeFillvector.cppsothat  it  pri  nts  the  lines 
(backwards)  from  last  to  first. 

6.  ChangeFillvector.cppsothat  it  concatenates  all  the 
elements  in  the  vector  into  a singlestring  before  printing 
it  out,  but  don't  try  to  add  line  numbering. 

7.  Display  a file  a line  at  a time,  waiting  for  the  user  to  press 
the  "Enter"  key  after  each  I i ne. 

8.  Create  a vector<float>end  put  25  floating-point  numbers 
into  it  using  a for  loop.  Display  the  vector 

9.  Create  three  vector<float>Dbjects  and  fill  the  first  two  as 
in  the  previous  exercise.  Write  a for  loop  that  adds  each 
correspond  i ng  el  ement  i n the  f i rst  two  vectois  and  puts 
the  resu  It  i n the  correspond  i ng  el  ement  of  the  thi  rd 
vector  Display  all  three  vectois. 

10.  Createa  vector<float>and  put  25  numbers  into  it  as  in 

the  previous  exercises.  Now  square  each  number  and  put 
the  result  back  into  the  same  location  in  the  vector 
D i spl  ay  the  vector  before  and  after  the  mu  I ti  pi  i cati  on . 
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3:  The  C in  C+  + 

Since  C++  is  based  on  C,  you  must  be  familiar  with^the 
syntax  of  C in  order  to  program  in  C++,  just  as  you 
must  be  reasonably  fluent  in  algebra  in  order  to  tackle 
calculus. 
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If  you've  never  seen  C before,  this  chapter  will  give  you  a decent 
background  in  thestyleof  C used  in  C++.  If  you  are  familiar  with 
thestyleof  C described  in  the  first  edition  of  Kernighan  & Ritchie 
(often  called  K&R  C),  you  will  find  some  new  and  different  features 
in  C++ as  well  as  in  Standard  C.  If  you  are  familiar  with  Standard 
C,you  should  skim  through  this  chapter  looking  for  features  that 
are  particular  to  C++.  Note  that  there  are  some  fundamental  C++ 
features  i ntroduced  here,  which  are  basic  ideas  that  are  aki  n to  the 
features  in  C or  often  modificationsto  the  way  that  C does  things. 
The  more  sophisticated  C++featureswill  not  be  introduced  until 
later  chapters. 

This  chapter  is  a fairly  fast  coverage  of  C constructs  and 
introduction  to  some  basic  C++ constructs,  with  the  understanding 
that  you've  had  some  experience  programming  in  another 
language.  A moregentle  introduction  to  C is  found  in  the  CD  ROM 
packaged  in  the  back  of  this  book,  titled  Thinking  in  C:  Foundations 
for  Java  & C++  by  Chuck  Allison  (published  by  MindView,  Inc,  and 
also  availableat  www.M indView.net).  This  is  a seminar  on  a CD 
ROM  with  the  goal  of  taking  you  carefully  through  the 
fundamentalsof  theC  language.  It  focuses  on  the  knowledge 
necessary  for  you  to  be  able  to  move  on  to  the  C++ or  Java 
languages  rather  than  trying  to  makeyou  an  expert  in  all  thedark 
corners  of  C (one  of  the  reasons  for  usi  ng  a hi  gher-l  evel  I anguage 
likeC++orJava  is  precisely  so  we  can  avoid  many  of  thesedark 
corners).  It  also  contains  exercises  and  guided  solutions.  Keep  in 
mind  that  because  this  chapter  goes  beyond  the  Thinking  in  C CD, 
the  CD  is  not  a replacement  for  this  chapter,  but  should  be  used 
instead  as  a preparation  for  this  chapter  and  for  the  book. 


Creating  functions 

In  old  (pre-Standard)  C,  you  could  call  a function  with  any  number 
or  type  of  arguments  and  the  compi  ler  wouldn't  complain. 
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Everything  seenned  fine  untii  you  ran  the  program.  You  got 
mysterious  resuits  (or  worse,  the  program  crashed)  with  no  hints  as 
to  why.  Theiack  of  heip  with  argument  passing  and  the  enigmatic 
bugs  that  resuited  is  probabiy  one  reason  why  C was  dubbed  a 
"high-ievei  assembiy  ianguage."  Pre-Standard  C programmers  just 
adapted  to  it. 

Standard  C and  C-H-useafeaturecaiied  function  prototyping.  With 
function  prototyping,  you  must  use  a description  of  the  types  of 
arguments  when  deciaring  and  defining  a function.  This 
description  is  the  "prototype."  When  thefunction  iscaiied,the 
compiier  uses  the  prototype  to  ensure  that  the  proper  arguments 
are  passed  in  and  that  the  return  vaiue  is  treated  correctiy.  if  the 
programmer  makes  a mistake  when  caiiing  the  function,  the 
compi  ier  catches  the  mistake. 

Essentiaiiy,  you  iearned  about  function  prototyping  (without 
nami  ng  it  as  such)  i n the  previ  ous  chapter,  si  nee  the  form  of 
function  deciaration  in  C-H- requires  proper  prototyping,  in  a 
fu ncti  on  prototype,  the  argu  ment  i i st  contai  ns  the  types  of 
arguments  that  must  be  passed  to  thefunction  and  (optionaiiy  for 
the  deciaration)  identifiersforthearguments.  The  order  and  type  of 
the  arguments  must  match  in  the  deciaration,  definition,  and 
function  caii.  Here's  an  exampie of  a function  prototype  in  a 
deciaration: 

int  translate (float  x,  float  y,  float  z); 

You  do  not  use  the  same  form  when  deciaring  variabies  in  function 
prototypes  as  you  do  in  ordinary  variabiedefinitions.  That  is,  you 
cannot  say:  floatx,  y,  zYou  must  indicate  the  type  of  each 
argument,  in  a function  deciaration,  the foii owing  form  isaiso 
acceptabie: 

int  translate (float,  float,  float); 


3:  The  C in  C-I--I- 


123 


Si  nee  the  compiler  doesn't  do  anything  but  check  for  types  when 
thefunction  iscalled,  the  identifiers  are  only  included  for  clarity 
when  someone  is  reading  the  code. 

In  thefunction  definition,  names  are  required  because  the 
argu  ments  are  referenced  i nsi  d e the  f u ncti  on : 

int  translate (float  x,  float  y,  float  z)  { 

X = y = z; 

//  . . . 

} 

It  turns  out  this  rule  applies  only  to  C.  In  C++,  an  argument  may  be 
unnamed  in  the  argument  list  of  thefunction  definition.  Sinceit  is 
unnamed,  you  cannot  use  it  in  thefunction  body,  of  course. 
Unnamed  arguments  are  allowed  togivetheprogrammer  away  to 
"reserve  space  in  theargument  list."  Whoever  uses  the  function 
must  still  call  thefunction  with  the  proper  arguments.  However, 
the  person  creating  thefunction  can  then  usethe  argument  in  the 
future  without  forcing  modification  of  code  that  cal  Is  the  function. 
This  option  of  ignoring  an  argument  in  the  list  is  also  possible  if 
you  leave  the  name  in,  but  you  will  get  an  annoying  warning 
message  about  the  value  being  unused  every  time  you  compile  the 
function.  The  warning  iseliminated  if  you  remove  the  name. 

C and  C++havetwo  other  ways  to  declare  an  argument  list.  If  you 
have  an  empty  argument  list,  you  can  declare  it  as  func(  )in  C++, 
which  tel  Is  the  compiler  there  are  exactly  zero  arguments.  You 
should  be  awarethat  this  only  means  an  empty  argument  list  in 
C++.  InC  it  means  "an  indeterminatenumber  of  arguments  (which 
isa"hole"  in  C si  nee  it  disables  type  checking  inthatcase).  In  both 
C and  C++,  the  declaration  func(void)pmeansan  empty  argument 
list.  The  void  keyword  means  "nothing"  in  this  case  (it  can  also 
mean  "no  type"  in  the  case  of  pointers,  as  you'll  see  later  in  this 
chapter). 

The  other  option  for  argument  lists  occurs  when  you  don't  know 
how  many  argumentsor  what  type  of  arguments  you  will  have; 
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this  iscalled  a i/ar/aWeargitymenf//sf.  This  "uncertain  argument  iist" 
is  represented  by  eiiipses  (...).  Defining  a function  with  a variabie 
argument  iist  issignificantiy  morecompiicated  than  defining  a 
regu i ar  f u ncti on . You  can  use  a vari  abi  e argu ment  i i st  for  a f u ncti  on 
that  has  a fixed  set  of  arguments  if  (for  some  reason)  you  want  to 
disabie  the  error  checks  of  function  prototyping.  Because  of  this, 
you  shouid  restrict  your  use  of  variabie  argu  ment  iiststo  C and 
avoid  them  in  C++(in  which,  asyou'ii  iearn,  there  are  much  better 
ai  ternati  ves).  H and  i i ng  vari  abi  e argu  ment  i i sts  i s descri  bed  i n the 
iibrary  section  of  your  iocai  C guide. 

Function  return  values 

A C++ function  prototype  must  specify  the  return  vaiuetypeof  the 
function  (in  C,  if  you  ieave  off  the  return  vaiuetypeitdefauitsto 
int).  The  return  type  specification  precedes  the  function  name.  To 
specify  that  no  vaiue  is  returned,  use  the  void  keyword.  This  wiii 
generate  an  error  if  you  try  to  return  a vaiuefromthefunction. 

H ere  are  some  compi  ete  f u ncti  on  prototypes: 

int  fl (void) ; //  Returns  an  int,  takes  no  arguments 
int  f2();  //  Like  fl()  in  C++  but  not  in  Standard  C! 
float  f3 (float,  int,  char,  double);  //  Returns  a float 
void  f4 (void) ; //  Takes  no  arguments,  returns  nothing 

To  return  a vaiue  from  a function,  you  usethe  return  statement, 
return  exits  the  function  back  to  the  poi  nt  right  after  the  function 
caii.  if  return  has  an  argument,  that  argument  becomes  the  return 
vaiueof  thefunction.  if  afunction  says  that  it  wiii  return  a 
parti cuiar  type,  then  each  return  statement  must  return  that  type. 
You  can  have  more  than  one  return  statement  in  afunction 
definition: 


//:  C03 : Return . cpp 
//  Use  of  "return" 
#include  <iostream> 
using  namespace  std; 

char  cfunc(int  i)  { 
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if(i  ==  0) 
return  ' a ' ; 
if(i  ==  1) 
return  ' g ' ; 
if(i  ==  5) 
return  ' z ' ; 
return  ' c ' ; 

} 

int  main  ( ) { 

cout  <<  "type  an  integer: 
int  val; 
cin  >>  val; 

cout  <<  cfunc(val)  <<  endl; 

} ///:- 

In  cfunc( ) thefirst  if  that  evaluates  to  true©(its  the  function  via 
the  return  statennent.  Notice  that  a function  declaration  isnot 
necessary  because  the  function  definition  appears  before  it  is  used 
in  main( ) so  the  compiler  knows  about  itfrom  that  function 
definition. 


Using  the  C function  iibrary 

All  the  functions  in  your  local  C function  library  are  available  while 
you  are  programming  in  C++.  You  should  look  hard  at  the  function 
library  before  defining  your  own  function  - there's  a good  chance 
that  someone  has  already  solved  your  problem  for  you,  and 
probably  given  it  a lot  more  thought  and  debugging. 

A word  of  caution,  though:  many  compilers  include  a lot  of  extra 
functions  that  make  life  even  easier  and  aretemptingto  use,  but  are 
not  part  of  the  Standard  C library.  If  you  are  certain  you  will  never 
want  to  move  the  application  to  another  platform  (and  who  is 
certain  of  that?),  go  ahead  -use  those  functions  and  make  your  life 
easier.  If  you  want  your  application  to  be  portable,  you  should 
restrictyourself  to  Standard  library  functions.  If  you  must  perform 
platform-specific  activities,  try  to  isolatethat  code  in  one  spot  so  it 
can  be  changed  easily  when  porting  to  another  platform.  In  C-H-, 
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platform-specific  activities  are  often  encapsulated  in  a class,  which 
isthe ideal  solution. 

The  formu  I a for  usi  ng  a I i brary  fu  ncti  on  i s as  fol  I ows:  f i rst,  f i nd  the 
function  in  your  programming  reference  (many  programming 
references  will  index  the  function  by  category  as  well  as 
alphabetically). Thedescription  of  thefunction  should  includea 
section  that  demonstrates  the  syntax  of  the  code.  The  top  of  this 
section  usually  has  at  least  one #includeline,  showing  you  the 
header  file  containing  the  function  prototype.  Du  plicate  this 
#includelinein  your  file  so  thefunction  is  properly  declared.  Now 
you  can  call  thefunction  in  the  same  way  it  appears  in  the  syntax 
section.  If  you  make  a mistake,  the  compiler  will  discover  it  by 
compari  ng  you  r fu  ncti  on  cal  I to  the  fu  ncti  on  prototype  i n the 
header  and  tell  you  aboutyour  error.  The  I inker  searches  the 
Standard  library  by  default,  so  that's  all  you  need  to  do:  include  the 
header fileand  call  thefunction. 


Creating  your  own  libraries  with  the  librarian 

You  can  collect  your  own  functions  together  into  a library.  Most 
programming  packages  come  with  a librarian  that  manages  groups 
of  object  modules.  Each  librarian  has  its  own  commands,  but  the 
general  idea  isthis:  if  you  want  to  createa  library,  makea  header 
file  containing  thefunction  prototypes  for  all  the  functions  in  your 
I i brary.  Put  thi s header  f i I e somew here  i n the  preprocessor's  search 
path,  either  in  the  local  directory  (so  it  can  befound  by  #include 
"header')  orintheincludedirectory  (soitcan  befound  by 
#include  <header>.  Nowtakeall  the  object  modules  and  hand 
them  to  the  librarian  along  with  a name  for  the  finished  library 
(most  librarians  require  a common  extension,  such  as  .libor  .a). 

P I ace  the  f i ni  shed  I i brary  where  the  other  I i brari  es  resi  de  so  the 
linker  can  find  it.  When  you  use  your  library,  you  will  haveto  add 
something  to  the  command  line  so  the  I inker  knows  to  search  the 
library  for  the  functions  you  call.  You  must  find  all  the  details  in 
your  local  manual,  si  nee  they  vary  from  system  to  system. 
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Controlling  execution 

This  section  covers  the  execution  controi  statennents  i n C++.  You 
must  befamiiiar  with  these  statements  before  you  can  read  and 
write  C or  C++ code. 

C++usesaii  of  C's execution  controi  statements. These inciudeif- 
elset  whiles  do-whil^for,  and  a seiection  statement  caiied  switch 
C++ aiso  aiiowstheinfamousgoto,  which  wiii  be  avoided  in  this 
book. 

True  and  false 

Aii  conditionai  statements  use  the  truth  orfaisehood  of  a 
conditionai  expression  to  determine  the  execution  path.  An 
exampieof  a conditionai  expression  is  A ==  B.  This  uses  the 
conditionai  operator  ==toseeif  thevariabieA  isequivaienttothe 
variabieB.  The  expression  produces  a Booiean  true  or  false  (these 
are  keywords  on iy  in  C++;  in  C an  expression  is  "true"  if  it 
evaiuatesto  a nonzero  vaiue).  Other  conditionai  operators  are  >,  <, 
>=,  etc.  Conditionai  statements  are  covered  morefuiiy  iater  in  this 
chapter. 

if-else 

The  if-elsestatement  can  exist  in  two  forms:  with  or  without  the 
else  The  two  forms  are: 

if (expression) 
statement 


or 


if (expression) 
statement 

else 

statement 

The  "expression"  evaiuatesto  trueor  false  The  "statement"  means 
either  a si  mpi e statement  termi  nated  by  a semi coi on  or  a 
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compound  statement,  which  is  a group  of  si mpie  statements 
enciosed  in  braces.  Any  time  the  word  "statement"  is  used,  it 
aiwaysimpiies  that  the  statement  is  si  mpie  or  compound.  Note  that 
this  statement  can  aiso  be  another  if,  so  they  can  be  strung  together. 

//:  COS : Ifthen . cpp 

//  Demonstration  of  if  and  if-else  conditionals 
#include  <iostream> 
using  namespace  std; 

int  main  ( ) { 

int  i ; 

cout  <<  "type  a number  and  'Enter'"  <<  endl; 
cin  >>  i; 
if (i  > 5) 

cout  <<  "It's  greater  than  5"  <<  endl; 
else 

if (i  < 5) 

cout  <<  "It's  less  than  5 " <<  endl; 
else 

cout  <<  "It's  equal  to  5 " <<  endl; 

cout  <<  "type  a number  and  'Enter'"  <<  endl; 
cin  >>  1; 
if(i  < 10) 

if (i  > 5)  //  "if"  is  just  another  statement 

cout  <<  "5  < 1 < 10"  <<  endl; 
else 

cout  <<  "i  <=  5"  <<  endl; 
else  //  Matches  "if  (1  < 10)" 
cout  <<  "1  >=  10"  <<  endl; 

} ///:- 

it  is  conventionai  to  indent  the  body  of  a controi  fiow  statement  so 
the  reader  may  easiiy  determine  where  it  begins  and  ends^. 


^ N ote  that  al  I conventi  ons  seem  to  end  after  the  agreement  that  some  sort  of 
indentation  take  place.  The  feud  between  styles  of  code  formatting  isunending.  See 
Appendix  A for  the  description  of  this  book's  coding  style. 
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while 

whiles  do-while, and  forcontrol  looping.  A statement  repeats  until 
the  control  ling  expression  evaluates  to  false  The  form  of  a while 
loop  is 

while (expression) 
statement 

The  expression  is  evaluated  once  at  the  beginning  of  the  loop  and 
again  before  each  further  iteration  of  the  statement. 

This  example  stays  in  the  body  of  thewhileloop  until  you  type  the 
secret  number  or  press  control-C. 

//:  COS : Guess . cpp 

//  Guess  a number  (demonstrates  "while") 

#include  <iostream> 
using  namespace  std; 

int  main  ( ) { 

int  secret  = 15; 
int  guess  = 0; 

//  "!="  is  the  "not-equal"  conditional: 
while (guess  !=  secret)  { //  Compound  statement 
cout  <<  "guess  the  number: 
cin  >>  guess; 

} 

cout  <<  "You  guessed  it!"  <<  endl; 

} ///:- 

The  whi Ids  conditional  expression  is  not  restricted  to  a simpletest 
as  in  the  example  above;  it  can  be  as  complicated  as  you  I ike  as  long 
as  it  produces  a trueorfalseresult.  You  will  even  see  code  where 
the  loop  has  no  body,  just  a bare  semicolon: 

while  (/*  Do  a lot  here  */) 

f 

In  these  cases,  the  programmer  has  written  the  conditional 
expression  not  only  to  perform  the  test  but  also  to  do  the  work. 


130 


Thinking  in  C+  + 


www.BruceEckel.com 


do-while 

The  form  of  do-whileis 

do 

statement 

while (expression)  ; 

The  do-whi  I ei  s (d  ifferent  from  the  whi  I e because  the  statement 
always  executes  at  least  once,  even  if  the  expression  evaluates  to 
false  the  first  time.  In  a regular  whilej  if  the  conditional  isfalsethe 
f i rst  ti  me  the  statement  never  executes. 

If  a do-whileis  used  in  G uess.cpp  the  variable  guessdoes  not 
need  an  initial  dummy  value,  since  it  is  initialized  bythedn 
statement  before  it  is  tested: 

//:  COS : Guess2 . cpp 

//  The  guess  program  using  do-while 
#include  <iostream> 
using  namespace  std; 

int  main  ( ) { 

int  secret  = 15; 

int  guess;  //  No  initialization  needed  here 
do  { 

cout  <<  "guess  the  number:  "; 

cin  >>  guess;  //  Initialization  happens 
} while (guess  !=  secret); 
cout  <<  "You  got  it!"  <<  endl; 

} ///:- 

For  some  reason,  most  programmers  tend  to  avoid  do-whi leand 
just  work  with  while 

for 

A for  loop  performs  initialization  before  the  first  iteration.  Then  it 
performs  conditional  testing  and,  at  the  end  of  each  iteration,  some 
form  of  "stepping."  The  form  of  the  for  loop  is: 

I for  ( initialization;  conditional;  step) 
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statement 


Any  of  theecpressions  initialization,  conditional,  or  step  may  be 
empty.  The /n/f/a//zaf/on  code  executes  once  at  the  very  beginning. 
The  concf/t/ona/  is  tested  before  each  iteration  (if  it  evaluates  to  false 
at  the  beginning,  thestatement  never  executes).  Attheend  of  each 
loop,  the  step  executes. 

for  loops  are  usually  used  for  "counting"  tasks: 

//:  COS : Charlist . cpp 

//  Display  all  the  ASCII  characters 

//  Demonstrates  "for" 

#include  <iostream> 
using  namespace  std; 

int  main  ( ) { 

for(int  1=0;  1 < 128;  i = 1 + 1) 

if  (1  !=  26)  //  ANSI  Terminal  Clear  screen 

cout  <<  " value:  " <<  1 
<<  " character:  " 

<<  char(i)  //  Type  conversion 
<<  endl; 

} ///:- 

You  may  notice  that  the  variable  i is  defined  at  the  point  where  it  is 
used,  instead  of  at  the  beginning  of  the  block  denoted  by  the  open 
curly  brace '{.This  is  in  contrast  to  traditional  procedural 
languages  (including  C),  which  require  that  all  variables  be  defined 
at  the  beginning  of  the  block.  This  will  be  discussed  later  in  this 
chapter. 

The  break  and  continue  keywords 

Insidethebody  of  any  of  the  looping  constructs  whilej  do-while, or 
for,  you  can  control  theflow  of  the  loop  using  break  and  continue 
break  quits  the  loop  without  executing  the  rest  of  the  statements  in 
the  loop,  continuestops  the  execution  of  the  current  iteration  and 
goes  back  to  the  beginning  of  theloopto  begin  a new  iteration. 


132 


Thinking  in  C+  + 


www.BruceEckel.com 


As  an  ©cample  of  break  and  continue  this  program  is  a very 
simple  menu  system: 


//:  C03:Menu.cpp 

//  Simple  menu  program  demonstrating 
//  the  use  of  "break"  and  "continue" 
#include  <iostream> 
using  namespace  std; 

int  main  ( ) { 

char  c;  //To  hold  response 
while (true ) { 

cout  <<  "MAIN  MENU:"  <<  endl; 

cout  <<  "1:  left,  r:  right,  q:  quit  -> 

cin  >>  c; 

if (c  ==  'q' ) 

break;  //  Out  of  "while (1)" 
if (c  ==  ' 1 ' ) { 

cout  <<  "LEFT  MENU:"  <<  endl; 
cout  <<  "select  a or  b:  "; 
cin  >>  c; 
if (c  ==  'a' ) { 

cout  <<  "you  chose  'a'"  <<  endl; 
continue;  //  Back  to  main  menu 

} 

if (c  ==  'b' ) { 

cout  <<  "you  chose  'b'"  <<  endl; 
continue;  //  Back  to  main  menu 

} 

else  { 

cout  <<  "you  didn't  choose  a or  b!" 
<<  endl; 

continue;  //  Back  to  main  menu 


if (c  ==  ' r ' ) { 

cout  <<  "RIGHT  MENU:"  <<  endl; 
cout  <<  "select  c or  d:  "; 
cin  >>  c; 
if (c  ==  'c' ) { 

cout  <<  "you  chose  'c'"  <<  endl; 
continue;  //  Back  to  main  menu 

} 

if (c  ==  'd' ) { 
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cout  <<  "you  chose  'd'"  <<  endl; 
continue;  //  Back  to  main  menu 

} 

else  { 

cout  <<  "you  didn't  choose  c or  d!" 
<<  endl; 

continue;  //  Back  to  main  menu 


cout  <<  "you  must  type  1 or  r or  q!"  <<  endl; 

} 

cout  <<  "quitting  menu..."  <<  endl; 

} ///:- 

If  the  user  selects 'q'  in  the  main  menu,  the  break  keyword  is  used 
to  quit,  otherwisetheprogram  just  continues  to  execute 
indefinitely.  After  each  of  the  sub-menu  selections,  the  continue 
keyword  isused  to  pop  back  up  to  the  beginning  of  the  while  loop. 

Thewhile(true)statement  istheequivalent  of  saying  "do  this  loop 
forever."  The  break  statement  al  I ows  you  to  break  out  of  thi  s 
infinitewhileloop  when  the  user  types  a 'q.' 

switch 

A switch  statement  selects  from  among  pieces  of  code  based  on  the 
valueof  an  integral  expression.  Its  form  is: 

switch (selector)  { 

case  integral-valuel  : statement;  break; 

case  integral-value2  : statement;  break; 

case  integral-valueS  : statement;  break; 

case  integral-value!  : statement;  break; 

case  integral-valueS  : statement;  break; 

(...) 

default:  statement; 

} 

Selector  is  an  ©cpression  that  produces  an  integral  value.  Theswitch 
compares  the  result  of  sefector  to  each  integral  value.  If  it  finds  a 
match,  the  corresponding  statement  (simple  or  compound) 
executes.  If  no  match  occurs,  thedefauitstatement  executes. 
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You  will  notice  in  the  definition  above  that  each  caseendswith  a 
break,  which  causes  execution  to  jump  to  the  end  of  the  switch 
body  (the  cl  osi  ng  brace  that  compi  etes  the  switch).  Thi  s i s the 
conventional  way  to  build  a switch  statement,  butthebreakis 
optional.  If  it  is  missing,  your  case  "drops  through"  to  the  one  after 
it.  That  is,  the  code  for  the  foil  owing  case  statements  execute  until  a 
breakis  encountered.  Although  you  don't  usually  want  this  kind  of 
behavior,  it  can  be  useful  to  an  experienced  programmer. 

The  switch  statement  is  a clean  way  to  implement  multi-way 
selection  (i.e.,  selecting  from  among  a number  of  different 
execution  paths),  but  it  requires  a selector  that  evaluates  to  an 
integral  value  at  compi  I e-time.  If  you  want  to  use,  for  example,  a 
stringobject  as  a selector,  it  won't  work  in  a switch  statement.  For 
a string  selector,  you  must  instead  use  a series  of  if  statements  and 
compare  the  stri  ng  i nsi  de  the  cond  i ti  onal . 

The  menu  example  shown  above  provides  a particularly  nice 
exampleof  a switch 

//:  COS :Menu2 . cpp 

//  A menu  using  a switch  statement 
#include  <iostream> 
using  namespace  std; 

int  main  ( ) { 

bool  quit  = false;  //  Flag  for  quitting 
while (quit  ==  false)  { 

cout  <<  "Select  a,  b,  c or  q to  quit: 
char  response; 
cin  >>  response; 
switch (response)  { 

case  'a'  : cout  <<  "you  chose  'a'"  <<  endl; 

break; 

case  'b'  : cout  <<  "you  chose  'b'"  <<  endl; 

break; 

case  'c'  : cout  <<  "you  chose  'c'"  <<  endl; 

break; 

case  'q'  : cout  <<  "quitting  menu"  <<  endl; 

quit  = true; 
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break; 

default  : cout  <<  "Please  use  a,b,c  or  q!" 
<<  endl; 


} ///:- 

Thequitflag  isabool,  short  for  "Boolean,"  which  isatype  you'll 
find  only  in  C++.  It  can  have  only  the  keyword  values  trueor  false 
Selecting  'q'  sets  thequitflag  to  true  The  next  time  the  selector  is 
eval  u ated , q u i t ==  f al  se'etu  r ns  f al se so  the  bod y of  the  w h i I e d oes 
not  execute. 


Using  and  misusing  goto 

The  goto  keyword  is  supported  in  C++,  since  it  exists  in  C.  Using 
goto  is  often  dismissed  as  poor  programming  style,  and  most  of  the 
time  it  is.  Anytime  you  use  goto,  look  at  your  code  and  see  if 
there's  another  way  to  do  it.  On  rare  occasions,  you  may  discover 
goto  can  solve  a problem  that  can't  be  solved  otherwise,  but  still, 
consider  it  carefully.  Here'san  examplethat  might  makea 
plausible  candidate: 

//:  COS : gotoKeyword. cpp 

//  The  infamous  goto  is  supported  in  C++ 

#include  <iostream> 
using  namespace  std; 

int  main  ( ) { 

long  val  = 0; 

for(int  i = 1;  i < 1000;  i++)  { 

for(int  j = 1;  j < 100;  j +=  10)  { 

val  = 1 * j; 
if(val  > 47000) 
goto  bottom; 

//  Break  would  only  go  to  the  outer  'for' 


bottom:  //  A label 
cout  <<  val  <<  endl; 
} ///:- 
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The  alternative  would  beto  set  a Boolean  that  is  tested  in  the  outer 
for  loop,  and  then  do  a break  from  the  inner  for  loop.  However,  if 
you  have  several  levelsof  foror  whilethiscould  get  awkward. 

Recursion 

Recursion  is  an  interesting  and  sometimes  useful  programming 
technique  whereby  you  call  the  function  that  you're  in.  Of  course,  if 
thisisall  you  do,  you'll  keep  cal  ling  the  function  you'rein  until 
you  run  out  of  memory,  so  there  must  be  someway  to  "bottom 
out"  the  recu  rsi  ve  cal  I . I n the  fol  I ow  i ng  exampi  e,  this"  bottomi  ng 
out"  is  accomplished  by  simply  saying  that  the  recursion  will  go 
only  until  the  cat  exceeds 'Z';2 

//:  COS : CatsInHats . cpp 
//  Simple  demonstration  of  recursion 
#include  <iostream> 
using  namespace  std; 

void  removeHat (char  cat)  { 

for (char  c = 'A';  c < cat;  C++) 
cout  <<  " 
if (cat  <=  'Z')  { 

cout  <<  "cat  " <<  cat  <<  endl; 
removeHat (cat  +1);  //  Recursive  call 
} else 

cout  <<  "VOOM! ! !"  <<  endl; 

} 

int  main  ( ) { 

removeHat  ( 'A'  ) ; 

} ///:- 

In  removeHat(  )you  can  seethataslong  as  cat  is  less  than  'Z', 
removeHat(  )will  be  called  from  within  removeHat(  )thus 
effecting  the  recu  rsi  on.  Each  ti  me  removeH  at(  )iscalled,  its 


2 Thanks  to  KrisC.  Matson  for  suggesting  this  exercise  topic. 
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argument  is  one  greater  than  the  current  cat  so  the  argument  keeps 
increasing. 

Recursion  is  often  used  when  evaluating  some  sort  of  arbitrarily 
complex  problem,  since  you  aren't  restricted  to  a particular  "size" 
for  the  solution  - the  function  can  just  keep  recursing  until  it's 
reached  the  end  of  the  problem. 


I ntroduction  to  operators 

You  can  think  of  operators  as  a special  type  of  function  (you'll  learn 
that  C++ operator  overloading  treats  operators  precisely  that  way). 
An  operator  takes  one  or  more  arguments  and  produces  a new 
value.  The  arguments  are  in  a different  form  than  ordinary  function 
cal  I s,  but  the  effect  i s the  same. 

From  your  previous  programming  experience,  you  should  be 
reasonably  comfortable  with  the  operators  that  have  been  used  so 
far.  The  concepts  of  addition  (+),  subtraction  and  unary  minus  (-), 
multiplication  (*),  division  (/),  and  assignment(=)  all  have 
essentially  the  same  meaning  in  any  programming  language.  The 
full  set  of  operators  is  enumerated  later  in  this  chapter. 

Precedence 

Operator  precedence  defines  the  order  in  which  an  expression 
evaluates  when  several  different  operators  are  present.  C and  C++ 
have  specif i c ru I es  to  determi  ne  the  order  of  eval  uati  on.  The  easi est 
to  remember  isthat  multiplication  and  division  happen  before 
addition  and  subtraction.  After  that,  if  an  expression  isn't 
transparent  to  you  it  probably  won't  be  for  anyone  reading  the 
code,  so  you  should  use  parentheses  to  makethe  order  of 
evaluation  explicit.  For  example: 

I A = X + Y - 2/2  + Z; 
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has  a very  different  meani  ng  from  the  same  statement  with  a 
particular  grouping  of  parentheses: 

I A = X+  (Y-2)/(2  + Z); 

(Try  evaluating  the  result  with  X =1,  Y =2,  and  Z =3.) 

Auto  increment  and  decrement 

C,  and  therefore  C++,  is  full  of  shortcuts.  Shortcuts  can  make  code 
much  easier  to  type,  and  sometimes  much  harder  to  read.  Perhaps 
theC  language  designers  thought  it  would  be  easier  to  understand 
atricky  pieceof  code  if  your  eyesdidn't  have  to  scan  as  large  an 
area  of  print. 

One  of  the  nicer  shortcuts  is  the  auto-increment  and  auto- 
decrement operators.  You  often  use  these  to  change  loop  variables, 
which  control  the  number  of  times  a loop  executes. 

The  auto-decrement  operator  is and  means  "decrease  by  one 
unit."  The  auto-i ncrement  operator  is'++'  and  means  "increase  by 
oneunit."  If  A isan  int  for  example,  the  express!  on  ++A  is 
equivalent  to  (A  =A  +}.  Auto-increment  and  auto-decrement 
operators  produce  the  value  of  the  variable  as  a result.  If  the 
operator  appears  before  the  variable,  (i.e.,  ++A),  the  operation  is 
first  performed  and  the  resulting  value  is  produced.  If  the  operator 
appears  after  the  variable  (i.e.  A ++),  thecurrent  valueis  produced, 
and  then  the  operation  is  performed.  For  example: 

//:  COS : Autolncrement . cpp 
//  Shows  use  of  auto-increment 
//  and  auto-decrement  operators. 

#include  <iostream> 
using  namespace  std; 

int  main  ( ) { 

int  i = 0; 

int  j = 0; 

cout  <<  ++i  <<  endl;  //  Pre-increment 

cout  <<  j++  <<  endl;  //  Post-increment 
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cout  <<  — i <<  endl;  //  Pre-decrement 
cout  <<  j — <<  endl;  //  Post  decrement 
} ///:- 

If  you've  been  wondering  about  the  name  "C++,"  now  you 
understand.  It  implies "onestep  beyond  C." 


I ntroduction  to  data  types 

Data  types  define  the  way  you  use  storage  (memory)  in  the 
programs  you  write.  By  specifying  a data  type,  you  tell  the 
compiler  how  to  create  a particular  piece  of  storage,  and  also  how 
to  mani  pu  I ate  that  storage. 

Data  types  can  be  built-in  or  abstract.  A built-in  data  type  is  one 
that  the  compiler  intrinsically  understands,  one  that  iswired 
directly  into  the  compiler.  The  types  of  built-in  data  are  almost 
identical  in  C and  C-H-.  In  contrast,  a user-defined  data  type  is  one 
that  you  or  another  programmer  create  as  a class.  These  are 
commonly  referred  to  as  abstract  data  types.  The  compiler  knows 
how  to  handle  built-in  types  when  it  starts  up;  it  "learns"  howto 
handle  abstract  datatypes  by  reading  header  files  containing  class 
declarations  (you'll  learn  about  this  in  later  chapters). 

Basic  built-in  types 

The  standard  C specification  for  built-in  types  (which  C-H- inherits) 
doesn't  say  how  many  bits  each  of  the  built-in  types  must  contain. 

I nstead , i t sti  pu  I ates  the  mi  ni  mu  m and  maxi  mu  m val  ues  that  the 
built-in  type  must  beableto  hold.  When  a machine  is  based  on 
binary,  this  maxi  mum  valuecan  be  directly  translated  intoa 
minimum  numberof  bits  necessary  to  hold  that  value.  However,  if 
a machineuses,  for  example,  binary-coded  decimal  (BCD)  to 
represent  numbers,  then  the  amount  of  space  in  the  machine 
required  to  hold  the  maximum  numbers  for  each  datatypewill  be 
different.  The  minimum  and  maximum  val  ues  that  can  be  stored  in 
the  various  data  types  are  defined  in  the  system  header  files 
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limits.hand  float.h(in  C++ you  will  generally  #include  <climits> 

and  <cfloat>instead). 


C and  C++ have  four  basic  built-in  datatypes,  described  here  for 
binary-based  machines.  A char  is  for  character  storage  and  uses  a 
mini  mum  of  8 bits  (one  byte)  of  storage,  although  it  may  be  larger. 
An  int  stores  an  integral  number  and  uses  a minimum  of  two  bytes 
of  storage.  The  f loatand  doubletypes  store  fl oati  ng-poi  nt 
numbers,  usually  in  IEEE  floating-point  format,  floatisfor  single- 
precision floating  point  and  doubleis for  double-precision  floating 
point. 

As  mentioned  previously,  you  can  define  variables  anywhere  in  a 
scope,  and  you  can  define  and  initializethem  at  the  same  time. 
Here's  how  to  define  variables  using  the  four  basic  data  types: 

//:  COS : Basic . cpp 

//  Defining  the  four  basic  data 

//  types  in  C and  Ct+ 

int  main  ( ) { 

//  Definition  without  initialization: 

char  protein; 

int  carbohydrates; 

float  fiber; 

double  fat; 

//  Simultaneous  definition  & initialization: 
char  pizza  = 'A',  pop  = 'Z'; 
int  dongdings  = 100,  twinkles  = 150, 
heehos  = 200; 

float  chocolate  = 3.14159; 

//  Exponential  notation: 
double  fudge_ripple  = 6e-4; 

} ///:- 

The  fi  rst  part  of  the  program  defi  nes  vari  abl  es  of  the  fou r basi c data 
types  without  initializing  them.  If  you  don't  initialize  a variable,  the 
Standard  says  that  its  contents  are  undefined  (usually,  this  means 
they  contain  garbage).  The  second  part  of  the  program  defines  and 
initializes  vari  abl  es  at  the  same  time(it'salways  best,  if  possible,  to 
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providean  initialization  value  at  the  point  of  definition).  Notice  the 
use  of  exponential  notation  i n the  constant  6e-4,  meaning  "6  times 
lOto  the  minus  fourth  power." 

bool,  true,  & false 

Before  bool  became  part  of  Standard  C++,  everyone  tended  to  use 
different  techniques  in  order  to  produce  Boolean-like  behavior. 
These  produced  portability  problems  and  could  introduce  subtle 
errors. 

The  Standard  C-H- bool  type  can  havetwo  states  expressed  by  the 
built-in  constants  true  (which  converts  to  an  integral  one)  and  false 
(which  converts  to  an  integral  zero).  All  three  names  are  keywords. 
In  addition,  some  language  elements  have  been  adapted: 


Element 

Usage  with  bool 

&&  II  ! 

Take  bool  arguments  and 
produce  bool  results. 

< > <= 

Produce  bool  results. 

if,  for 

Conditional  expressions 

while  do 

convert  to  bool  val  ues. 

7 . 
■ ■ 

Fi  rst  operand  converts  to  bool 
value. 

Because  there's  a lot  of  existing  code  that  uses  an  Intto  represent  a 
flag,  the  compiler  will  implicitly  convert  from  an  Intto  a bool 
( nonzero  val  u es  w i 1 1 prod  u ce  tru e w h i I e zero  val  u es  prod  u ce  fal seO . 
Ideally,  the  compiler  will  give  you  a warning  as  a suggestion  to 
correct  the  si  tu ati  on . 

An  idiom  that  falls  under  "poor  programming  style"  is  the  use  of 
++ to  set  a flag  to  true.  This  is  still  allowed,  but  d^recated,  which 
means  that  at  some  ti  me  i n the  future  it  wi  1 1 be  made  i I legal . The 
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problem  isthat  you're  making  an  implicit  type  conversion  from 
bool  to  i nt  i ncrementi  ng  the  val  ue  (perhaps  beyond  the  range  of 
the  normal  bool  valuesof  zero  and  one),  and  then  implicitly 
converting  it  back  again. 

Pointers  (which  will  be  introduced  later  in  this  chapter)  will  also  be 
automatically  converted  to  bool  when  necessary. 

Specifiers 

Specifiers  modify  the  meanings  of  the  basic  built-in  types  and 
expand  them  to  a much  larger  set.  There  are  four  specifiers:  long 
short;  signed,  and  unsigned 

longand  shortmodify  the  maximum  and  minimum  values  that  a 
datatypewill  hold.  A plain  intmust  beat  least  the  size  of  a short 
The  size  hierarchy  for  integral  types  is:  shortint  int  longint  All 
the  sizes  could  conceivably  be  the  same,  as  long  as  they  satisfy  the 
minimum/  maximum  value  requirements.  On  a machine  with  a &T 
bit  word,  for  instance,  all  the  data  types  might  be  64  bits. 

The  size  hierarchy  for  floating  point  numbers  is:  float  double  and 
longdouble  "long  float"  is  not  a legal  type.  There  are  no  short 
floating-point  numbers. 

The  signed  and  unsignedspecifierstell  the  compiler  how  to  use 
the  sign  bit  with  integral  types  and  characters  (floating-point 
numbers  always  contain  a sign).  An  unsignednumber  does  not 
keep  track  of  the  sign  and  thus  has  an  extra  bit  available,  so  it  can 
store  posi  ti  ve  n u m bers  tw  i ce  as  I arge  as  the  posi  ti  ve  n u mbers  that 
can  be  stored  in  a signed  number,  signedisthedefaultand  isonly 
necessary  with  char  char  may  or  may  not  default  to  signed  By 
specifying  signed  char,  you  force  the  sign  bit  to  be  used. 

The  fol  I owi ng  example  shows  the  size  of  the  data  types  i n bytes  by 
using  the  si  zeof  operator,  introduced  later  in  this  chapter: 

I //:  COS : Specify . cpp 


3:  The  C in  C-I--I- 


143 


//  Demonstrates  the  use  of  specifiers 
#include  <iostream> 
using  namespace  std; 

int  main  ( ) { 

char  c; 

unsigned  char  cu; 
int  i ; 

unsigned  int  iu; 
short  int  is; 

short  iis;  //  Same  as  short  int 
unsigned  short  int  isu; 
unsigned  short  iisu; 
long  int  il; 

long  iil;  //  Same  as  long  int 

unsigned  long  int  ilu; 

unsigned  long  iilu; 

float  f; 

double  d; 

long  double  id; 


cout 

<< 

"\n 

char=  " 

« sizeof (c) 

<< 

"\n 

unsigned 

char  = " <<  sizeof (cu) 

<< 

"\n 

int  = " 

<<  sizeof (i) 

<< 

"\n 

unsigned 

int  = " <<  sizeof (iu) 

<< 

"\n 

short  = 

" <<  sizeof  (is) 

<< 

"\n 

unsigned 

short  = " <<  sizeof (isu 

<< 

"\n 

long  = " 

<<  sizeof (il) 

<< 

"\n 

unsigned 

long  = " <<  sizeof  (ilu) 

<< 

"\n 

float  = 

" <<  sizeof (f) 

<< 

"\n 

double  = 

" <<  sizeof (d) 

<< 

"\n 

long  double  = " <<  sizeof (id) 

<< 

endl 

• r 

} ///:- 

Be  aware  that  the  results  you  get  by  running  this  program  will 
probably  be  different  from  one  machine/'  operating 
system/  compiler  to  the  next,  si  nee  (as  mentioned  previously)  the 
only  thing  that  must  be  consistent  is  that  each  different  type  hold 
the  minimum  and  maximum  values  specified  in  the  Standard. 

When  you  are  modifying  an  intwith  shortor  long,  the  keyword  int 
i s opti  onal , as  show  n above. 
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I ntroduction  to  pointers 

Whenever  you  run  a program,  it  is  first  loaded  (typically  from  disk) 
i nto  the  computer's  memory.  Thus,  al  I el  ements  of  you  r program 
are  located  somewhere  in  memory.  Memory  is  typically  laid  out  as 
a sequential  series  of  memory  locations;  we  usually  refer  to  these 
locations  as  eight-bit  bytes  but  actually  the  size  of  each  space 
depends  on  the  architecture  of  the  particular  machine  and  is 
usually  called  that  machine's  word  size.  Each  space  can  be  uniquely 
distinguished  from  all  other  spaces  by  Its  address.  For  the  purposes 
of  this  discussion,  we'll  just  say  that  all  machines  use  bytes  that 
have  sequential  addresses  starting  at  zero  and  going  up  to  however 
much  memory  you  have  in  your  computer. 

Since  your  program  lives  in  memory  while  it's  being  run,  every 
element  of  your  program  has  an  address.  Suppose  we  start  with  a 
simple  program: 

//:  COS : YourPetsl . cpp 
#include  <iostream> 
using  namespace  std; 

int  dog,  cat,  bird,  fish; 

void  f ( int  pet ) { 

cout  <<  "pet  id  number:  " <<  pet  <<  endl; 

} 

int  main  ( ) { 

int  i,  j,  k; 

} ///:- 

Each  of  the  el  ements  in  this  program  has  a location  in  storage  when 
the  program  is  running.  Even  the  function  occupies  storage.  As 
you'll  see,  it  turns  out  that  what  an  element  is  and  thewayyou 
define  it  usually  determines  the  area  of  memory  where  that 
element  is  placed. 

Thereisan  operator  in  C and  C-H- that  will  tell  you  the  address  of 
an  element.  This  is  the  operator.  All  you  do  isprecedethe 
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identifier  name  with  '&'and  it  will  producetheaddressof  that 
identifier.  You rPetsLcppcan  be  modified  to  print  out  the  addresses 
of  all  its  elements,  likethis: 

//:  COS : YourPets2 . cpp 
#include  <iostream> 
using  namespace  std; 

int  dog,  cat,  bird,  fish; 


void  f ( int 

pet) 

cout 

} 

<< 

"pet 

id 

number:  " <<  pet  <<  endl; 

int  main  ( ) 

{ 

int 

i/  j 

, k; 

cout 

<< 

"f  0 : 

!f 

<<  (long)&f  <<  endl; 

cout 

<< 

"dog : 

!f 

<<  (long)&dog  <<  endl; 

cout 

<< 

"cat : 

!? 

<<  (long)&cat  <<  endl; 

cout 

<< 

"bird 

. IT 

<<  (long)&bird  <<  endl; 

cout 

<< 

"fish 

. IT 

<<  (long)&fish  <<  endl; 

cout 

<< 

<< 

(long)&i  <<  endl; 

cout 

<< 

»f  j . Tf 

<< 

(long) & j <<  endl ; 

cout 

<< 

"k:  " 

<< 

(long)&k  <<  endl; 

} ///:- 

The  (long)is  a cast.  It  says  "Don't  treat  this  as  if  it's  normal  type, 
instead  treat  it  as  a long"  The  cast  isn't  essential,  but  if  it  wasn't 
there,  the  addresses  would  have  been  printed  out  in  hexadecimal 
instead,  so  casting  to  a long  makes  things  a little  more  readable. 

The  results  of  this  program  will  vary  depending  on  your  computer, 
OS,  and  all  sorts  of  other  factors,  but  it  will  always  give  you  some 
interesting  insights.  For  a single  run  on  my  computer,  the  results 
looked  likethis: 

f 0 : 4198736 
dog:  4323632 
cat:  4323636 
bird:  4323640 
fish:  4323644 
i:  6684160 
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j:  6684156 
k:  6684152 

You  can  see  how  the  variables  that  are  defined  insidemain(  )arein 
a different  area  than  the  variables  defined  outside  of  mainO  you'll 
understand  why  as  you  learn  more  about  the  language.  Also,  f( ) 
appears  to  be  i n its  own  area;  code  is  typical  ly  separated  from  data 
in  memory. 

A nother  i nteresti  ng  thi  ng  to  note  i s that  vari  abl  es  defi  ned  one  ri  ght 
after  the  other  appear  to  be  placed  contiguously  in  memory.  They 
are  separated  by  the  number  of  bytes  that  are  required  bytheirdata 
type.  Here,  the  only  data  type  used  isint  and  catisfour  bytes 
away  from  dog,  bird  isfour  bytes  away  from  cat  etc.  So  it  would 
appear  that,  on  this  machine,  an  intis  four  bytes  long. 

Other  than  this  interesting  experiment  showing  how  memory  is 
mapped  out,  what  can  you  do  with  an  address?  The  most 
important  thing  you  can  do  is  store  it  inside  another  vari  able  for 
later  use.C  and  C++ have  a special  typeof  variable  that  holds  an 
ad  d ress.  This  vari  abl  e i s cal  I ed  a pointer. 

The  operator  that  defines  a pointer  isthesame  astheoneused  for 
multiplication:  The  compiler  knowsthat  it  isn't  multiplication 

becauseof  the  context  in  which  it  is  used,  as  you  will  see. 

When  you  definea  pointer,  you  must  specify  the  type  of  variableit 
points  to.  You  start  outby  giving  the  type  name,  then  instead  of 
immediately  giving  an  identifier  for  the  vari  able,  you  say  "Wait,  it's 
a pointer"  by  inserting  a star  between  thetypeand  the  identifier.  So 
a pointer  to  an  intlooks  likethis: 

int*  ip;  //  ip  points  to  an  int  variable 

The  association  of  the'*' with  the  type  looks  sensible  and  reads 
easily,  but  it  can  actually  be  a bit  deceiving.  Your  inclination  might 
be  to  say  "intpointer"  as  if  it  is  a single  discrete  type.  However, 
with  an  intor  other  basic  data  type,  it's  possibleto  say: 
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int  a,  b,  c; 


whereas  with  a pointer,  you'd  liketo  say: 

int*  ipa,  ipb,  ipc; 

C syntax  (and  by  inheritance,  C++ syntax)  does  not  aiiow  such 
sensibie  expressions,  in  the  definitions  above,  oniy  ipa  is  a pointer, 
but  i pb  and  i pc  are  ord  i nary  i nts  (you  can  say  that  "*  bi  nds  more 
tightiy  to  the  identifier").  Consequentiy,  the  best  resuits  can  be 
achieved  by  using  oniy  onedefinition  per  iine;  you  stiii  get  the 
sensi  bi  e syntax  w i thout  the  conf  usi  on : 

int*  ipa; 
int*  ipb; 
int*  ipc; 

Sincea  generai  guideiine for  C++ programming  is  that  you  shouid 
aiwaysinitiaiizeavariabie  at  the  point  of  definition,  this  form 
actuaiiy  works  better.  For  exampie,  the  variabies  above  are  not 
initiaiized  to  any  particuiar  vaiue;  they  hoid  garbage,  it's  much 
better  to  say  someth!  ng  i i ke: 

int  a = 47; 
int*  ipa  = &a; 

Now  both  a and  ipa  have  been  initiaiized,  and  ipahoidsthe 
address  of  a. 

Once  you  havean  initiaiized  pointer,  the  most  basic  thing  you  can 
do  with  it  is  to  use  it  to  modify  the  vaiue  it  points  to.  To  access  a 
variabiethrough  a pointer,  you  dereference  the  pointer  using  the 
same  operator  that  you  used  to  define  it,  i ike  this: 

*ipa  = 100; 

N ow  a contai  ns  the  vai  ue  100  i nstead  of  47. 

These  are  the  basics  of  pointers:  you  can  hoid  an  address,  and  you 
can  use  that  ad  dress  to  modify  the  originai  variabie.  But  the 
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question  still  rennains:  why  do  you  want  to  modify  one  variable 
using  another  variable  as  a proxy? 

For  this  introductory  view  of  pointers,  we  can  put  the  answer  into 
two  broad  categories: 

1.  To  change  "outside  objects"  from  within  a function.  This  is 
perhaps  the  most  basic  use  of  pointers,  and  it  will  be 
examined  here. 

2.  To  achieve  many  other  clever  programming  techniques, 
which  you'll  learn  about  in  portionsof  the  rest  of  the  book. 

Modifying  the  outside  object 

Ordinarily,  when  you  pass  an  argument  to  a function,  a copy  of 
that  argument  is  made  inside  the  function.  This  is  referred  to  as 
pass-by-value.  You  can  see  the  effect  of  pass-by-value  in  the 
following  program: 

//:  COS : PassByValue . cpp 
#include  <iostream> 
using  namespace  std; 

void  f (int  a)  { 

cout  <<  "a  = " <<  a <<  endl; 
a = 5; 

cout  <<  "a  = " <<  a <<  endl; 

} 

int  main  ( ) { 

int  X = 47; 

cout  <<  "x  = " <<  X <<  endl; 
f (x)  ; 

cout  <<  "x  = " <<  X <<  endl; 

} ///:- 

lnf(),ais  a local  variable,  so  it  exists  only  for  the  duration  of  the 
function  call  tof( ).  Because  it's  a function  argument,  thevalueof  a 
is  initialized  by  the  arguments  that  are  passed  when  thefunction  is 
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called;  in  main(  )the  argument  isx,  which  hasa  value  of  47,  so  this 
valueiscopied  intoawhen f(  )iscalled. 

When  you  run  this  program  you'll  see: 

X = 47 
a = 47 
a = 5 
X = 47 

Initially,  of  course,  x is  47.  When  f( ) is  cal  led,  temporary  space  is 
created  to  hold  the  variable  a for  the  duration  of  the  function  call, 
and  a is  initialized  by  copying  thevalueofx,  which  is  verified  by 
printing  it  out.  Of  course,  you  can  change  the  value  of  a and  show 
that  it  is  changed.  But  when  f( ) is  completed,  the  temporary  space 
that  was  created  for  a disappears,  and  we  see  that  the  only 
connection  that  ever  existed  between  a and  x happened  when  the 
val ue  of  X was  copied  into  a. 

When  you're  insidef(  ),x\sthe  outside  object  (my  terminology),  and 
changing  the  local  variable  does  not  affect  the  outside  object, 
naturally  enough,  since  they  are  two  separate  locations  in  storage. 
But  what  if  you  do  want  to  modify  the  outside  object?  This  is  where 
pointers  come  in  handy.  In  a sense,  a pointer  is  an  alias  for  another 
variable.  So  if  we  pass  a po/nter  into  a function  instead  of  an 
ordinary  value,  weare  actually  passing  an  alias  to  the  outside 
object,  enabling  the  function  to  modify  that  outside  object,  likethis: 

//:  COS : PassAddress . cpp 
#include  <iostream> 
using  namespace  std; 

void  f (int*  p)  { 

cout  <<  "p  = " <<  p <<  endl; 
cout  <<  "*p  = " <<  *p  <<  endl; 

*p  = 5; 

cout  <<  "p  = " <<  p <<  endl; 

} 

int  main  ( ) { 
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int  X = 47; 

cout  <<  "x  = " <<  X <<  endl; 
cout  <<  "&x  = " <<  &x  <<  endl; 
f (&x) ; 

cout  <<  "x  = " <<  X <<  endl; 

} ///:- 

Now  f( ) takes  a pointer  as  an  argument  and  dereferences  the 
pointer  during  assignment,  and  this  causes  the  outside  object  x to 
be  modified.  The  output  is: 

X = 47 

&x  = 0065FE00 
p = 0065FE00 
*p  = 47 
p = 0065FE00 
X = 5 

Notice  that  the  value  contained  in  p is  the  same  as  the  address  of  x 
- the  poi  nter  p does  i ndeed  point  to  x.  If  that  isn't  convi  nd  ng 
enough,  when  p is  dereferenced  to  assign  the  values,  weseethat 
thevalueof  X isnow  changed  to  5 as  well. 

Thus,  passing  a pointer  into  a function  will  allow  that  function  to 
modify  the  outside  object.  You'll  see  plenty  of  other  uses  for 
pointers  later,  but  this  is  arguably  the  most  basic  and  possibly  the 
most  common  use. 


Introduction  to  C++  references 

Pointers  work  roughly  the  same  in  C and  in  C++,  but  C++ adds  an 
additional  way  to  pass  an  address  into  a function.  This  is  pass- by- 
reference  and  it  exists  in  several  other  programming  languages  so  it 
was  not  a C-h- invent! on. 

Your  initial  perception  of  references  may  be  that  they  are 
unnecessary,  that  you  could  write  all  your  programs  without 
references.  I n general,  this  is  true,  with  the  exception  of  a few 
important  places  that  you'll  learn  about  later  in  the  book.  You'll 
also  learn  more  about  references  later,  but  the  basic  idea  is  the  same 
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as  the  demonstration  of  pointer  use  above:  you  can  pass  the 
address  of  an  argument  using  a reference.  Thedifference  between 
references  and  pointers  isthat  ca/Z/ng  a function  that  takes 
references  iscieaner,  syntacticaiiy,  than  caiiing  a function  that  takes 
pointers  (and  it  is  exactiy  this  syntactic  difference  that  makes 
references  essentiai  in  certain  situations),  if  PassAddress.cppis 
modified  to  use  references,  you  can  see  the  difference  in  the 
function  caii  in  main( ) 

//:  C03 : PassReference . cpp 
#include  <iostream> 
using  namespace  std; 

void  f (int&  r)  { 

cout  <<  "r  = " <<  r <<  endl; 
cout  <<  "&r  = " <<  &r  <<  endl; 
r = 5; 

cout  <<  "r  = " <<  r <<  endl; 

} 

int  main  ( ) { 

int  X = 47; 

cout  <<  "x  = " <<  X <<  endl; 
cout  <<  "&x  = " <<  &x  <<  endl; 
f (x) ; //  Looks  like  pass-by-value, 

//  is  actually  pass  by  reference 
cout  <<  "x  = " <<  X <<  endl; 

} ///:- 

in  f(  ys  argument  ii St,  instead  of  saying  int* to  pass  a pointer,  you 
say  int&  to  pass  a reference.  insidef( ),  if  you  just  say  'r'  (which 
wouid  produce  the  address  if  r were  a pointer)  you  get  the  value  in 
the  variable  that  r references,  if  you  assign  to  r,  you  actuai  iy  assign  to 
the  variabie  that  r references,  i n fact,  the  oniy  way  to  get  the 
address  that's  heid  insider  is  with  the'&'  operator. 

i n main( ) you  can  seethe  key  effect  of  references  in  the  syntax  of 
the  cai  i to  f(),  which  isjustf(x).  Even  though  thisiooksiikean 
ordinary  pass-by-vaiue,  theeffect  of  the  reference  isthat  it  actuaiiy 
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takes  the  address  and  passes  it  in,  rather  than  making  a copy  of  the 
value.  The  output  is: 

X = 47 

&x  = 0065FE00 
r = 47 

&r  = 0065FE00 
r = 5 
X = 5 

So  you  can  see  that  pass-by-reference  allows  a function  to  modify 
the  outside  object,  just  like  passing  a pointer  does  (you  can  also 
observe  that  the  reference  obscures  the  fact  that  an  address  is  bei  ng 
passed;  this  will  be  examined  later  in  the  book).  Thus,  for  this 
simple  introduction  you  can  assume  that  references  arejust  a 
syntactical  ly  different  way  (someti  mes  referred  to  as  "syntactic 
sugar" ) to  accompi  i sh  the  same  thi  ng  that  poi  nters  do:  al  I ow 
functions  to  change  outside  objects. 

Pointers  and  references  as  modifiers 

So  far,  you've  seen  the  basic  data  types  char,  int  float, and  doubla 
along  with  the  specifiers  signed,  unsigned  short, and  long  which 
can  be  used  with  the  basic  data  types  in  almost  any  combination. 
Now  we've  added  poi  nters  and  references  that  are  orthogonal  to 
the  basic  data  types  and  specifiers,  so  the  possible  combi  nations 
have  just  tripled: 

//:  COS : AllDef initions . cpp 

//  All  possible  combinations  of  basic  data  types, 

//  specifiers,  pointers  and  references 
#include  <iostream> 
using  namespace  std; 

void  fl (char  c,  int  i,  float  f,  double  d) ; 

void  f2 (short  int  si,  long  int  li,  long  double  id); 

void  fS (unsigned  char  uc,  unsigned  int  ui, 

unsigned  short  int  usi,  unsigned  long  int  uli); 
void  f4 (char*  cp,  int*  ip,  float*  fp,  double*  dp) ; 
void  f5 (short  int*  sip,  long  int*  lip, 
long  double*  Idp) ; 
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void  f6 (unsigned  char*  ucp,  unsigned  int*  uip, 
unsigned  short  int*  usip, 
unsigned  long  int*  ulip) ; 

void  f7 (char&  cr,  int&  ir,  floats  fr,  doubles  dr) ; 
void  f8 (short  intS  sir,  long  intS  lir, 
long  doubles  Idr) ; 

void  f9 (unsigned  chars  ucr,  unsigned  intS  uir, 
unsigned  short  intS  usir, 
unsigned  long  intS  ulir)  ; 

int  main  ( ) { } / / / : ~ 

Poi  nters  an(d  references  also  work  when  pass!  ng  objects  i nto  and 
out  of  functions;  you'll  learn  about  this  in  a later  chapter. 

There'soneother  type  that  works  with  pointers:  void.  If  you  state 
that  a poi  nter  I s a voi d*  it  means  that  any  type  of  add  ress  at  al  I can 
be  assigned  to  that  poi  nter  (whereas  if  you  have  an  int*,  you  can 
assign  only  the  address  of  an  int  variable  to  that  pointer).  For 
example: 

//:  COS : VoidPointer . cpp 
int  main  ( ) { 

void*  vp; 
char  c; 
int  i ; 
float  f; 
double  d; 

//  The  address  of  ANY  type  can  be 
//  assigned  to  a void  pointer: 
vp  = Sc; 
vp  = Si; 
vp  = S f ; 
vp  = Sd; 

} ///:- 

Once  you  assign  to  a void* you  lose  any  information  about  what 
type  it  is.  This  means  that  before  you  can  use  the  poi  nter,  you  must 
cast  it  to  the  correct  type: 

// : COS : CastFromVoidPointer . cpp 
int  main  ( ) { 

int  i = 99; 
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void*  vp  = &i; 

//  Can't  dereference  a void  pointer: 

//  *vp  =3;  //  Compile-time  error 

//  Must  cast  back  to  int  before  dereferencing: 

* ( (int*) vp)  = 3; 

} ///:- 

The  cast  (int*)vptakes  the  void*  and  tel  Is  the  compiler  to  treat  it  as 
an  int*,  and  thus  it  can  be  successfully  dereferenced.  You  might 
observethat  this  syntax  is  ugly,  and  it  is,  but  it's  worse  than  that- 
the  void*  i ntroduces  a hole  i n the  language's  type  system.  That  is,  it 
allows,  or  even  promotes,  the  treatment  of  one  type  as  another 
type.  In  the  example  above,  I treat  an  int  as  an  i nt  by  casting  vp  to 
an  int*,  but  there's  nothing  that  says  I can't  cast  it  to  a char*or 
doubie*  which  would  modify  a different  amount  of  storage  that 
had  been  allocated  for  the  int  possibly  crashing  the  program.  In 
general,  void  pointers  should  be  avoided,  and  used  only  in  rare 
special  cases,  the  li  kes  of  which  you  won't  be  ready  to  consider 
until  significantly  later  in  the  book. 

Y ou  cannot  have  a void  reference,  for  reasons  that  will  be  explai  ned 
in  Chapter  11. 

Scoping 

Scoping  rules  tell  you  wherea  variable  is  valid,  whereit  iscreated, 
and  where  it  gets  destroyed  (i.e.,  goesoutof  scope).  The  scope  of  a 
variable  extends  from  the  point  whereit  isdefined  to  thefirst 
closing  brace  that  matches  the  closest  opening  brace  before  the 
variable  was  defined.  That  is,  a scope  is  defined  by  its  "nearest"  set 
of  braces.  To  i 1 1 ustrate: 

//:  C03 : Scope . cpp 
//  How  variables  are  scoped 
int  main  ( ) { 

int  scpl; 

//  scpl  visible  here 
{ 

//  scpl  still  visible  here 
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// 


int 

// 

//. 


scp2 ; 

scp2  visible 


here 


//  scpl  & scp2  still  visible  here 

//.  . 

int  scp3; 

//  scpl,  scp2  & scp3  visible  here 

/ / ... 

} //  < — scp3  destroyed  here 
//  scp3  not  available  here 
//  scpl  & scp2  still  visible  here 

/ / ... 

} //  < — scp2  destroyed  here 
//  scp3  & scp2  not  available  here 
//  scpl  still  visible  here 

//.  . 

} //  < — scpl  destroyed  here 
///:- 

The  example  above  shows  when  variables  are  visible  and  when 
they  are  unavai  lable  (that  is,  when  they  go  out  of  scope).  A variable 
can  be  used  only  when  inside  its  scope.  Scopes  can  be  nested, 
indicated  by  matched  pairs  of  braces  inside  other  matched  pairs  of 
braces.  Nesting  means  that  you  can  access  a variable  in  a scope  that 
encloses  the  scope  you  are  in.  In  the  example  above,  the  variable 
scp  1 i s avai  I abl  e i nsi  d e al  I of  the  other  scopes,  while  scp3  i s 
available  only  in  the  innermost  scope. 

Defining  variabies  on  the  fiy 

As  noted  earlier  in  this  chapter,  there  is  a significant  difference 
between  C and  C++when  defining  variables.  Both  languages 
require  that  variables  bedefined  before  they  are  used,  butC  (and 
many  other  traditional  procedural  languages)  forces  you  to  define 
all  thevariables  at  the  beginning  of  a scope,  so  that  when  the 
compiler  creates  a block  it  can  allocate  space  for  those  variables. 

While  reading  C code,  a block  of  variable  definitions  is  usually  the 
first  thing  you  see  when  entering  a scope.  Declaring  all  variables  at 
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the  beginning  of  thebiock  requires  the  programmer  to  write  in  a 
parti cuiar  way  because  of  the  impiementati  on  detaiisof  the 
ianguage.  Most  peopie  don't  know  aii  the  variabies  they  are  going 
to  use  beforethey  write  the  code,  so  they  must  keep  jumping  back 
to  the  beginning  of  thebiock  to  insert  new  variabies,  which  is 
awkward  and  causes  errors.  These  variabiedefinitionsdon't 
usuaiiy  mean  much  to  the  reader,  and  they  actuaiiy  tend  to  be 
confusing  because  they  appear  apart  from  the  context  in  which  they 
are  used. 

C++(notC)  aiiowsyou  to  define  variabies  any  where  in  a scope,  so 
you  can  definea  variabieright  before  you  use  it.  in  addition,  you 
can  initiaiize the  variabieat  the  point  you  define  it,  which  prevents 
acertain  dass  of  errors.  Defining  variabies  this  way  makes  the  code 
much  easier  to  write  and  reduces  the  errors  you  get  from  being 
forced  to  jump  back  and  forth  within  a scope,  it  makes  the  code 
easier  to  understand  because  you  seeavariabie  defined  in  the 
context  of  its  use.  This  is  especiai iy  i mportant  when  you  are 
defining  and  initiaiizing  a variabieat  the  same  time-  you  can  see 
the  meani  ng  of  the  i niti ai  izati on  vai  ue  by  the  way  the  vari abi  e i s 
used. 

You  can  ai  so  define  vari  abi  es  inside  the  controi  expressions  offer 
ioopsand  whileioops,  inside  the  conditionai  of  an  if  statement, 
and  insidetheseiector  statement  of  a switch  Here's  an  exampie 
show  i ng  on-the-f  i y vari  abi  e def  i ni  ti  ons: 

//:  COS : OnTheFly . epp 
//  On-the-f ly  variable  definitions 
#include  <iostream> 
using  namespace  std; 

int  main  ( ) { 

//.  . 

{ //  Begin  a new  scope 

int  q = 0;  //  C requires  definitions  here 

//.  . 

//  Define  at  point  of  use: 
for(int  i = 0;  i < 100;  i++)  { 
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q++;  //  q comes  from  a larger  scope 
//  Definition  at  the  end  of  the  scope: 
int  p = 12; 

} 

int  p = 1;  //A  different  p 

} //  End  scope  containing  q & outer  p 
cout  <<  "Type  characters:"  <<  endl; 
while  (char  c = cin.getO  !=  'q')  { 

cout  <<  c <<  " wasn't  it"  <<  endl; 
if (char  x = c ==  'a'  | | c ==  'b') 

cout  <<  "You  typed  a or  b"  <<  endl; 
else 

cout  <<  "You  typed  " <<  x <<  endl; 

} 

cout  <<  "Type  A,  B,  or  C"  <<  endl; 
switch(int  i = cin.getO)  { 

case  'A':  cout  <<  "Snap"  <<  endl;  break; 
case  'B':  cout  <<  "Crackle"  <<  endl;  break; 
case  'C':  cout  <<  "Pop"  <<  endl;  break; 
default:  cout  <<  "Not  A,  B or  C ! " <<  endl; 


} ///:- 

In  the  innermost  scope,  p is  defined  right  before  the  scope  ends,  so 
it  is  really  a useless  gesture  (but  it  shows  you  can  define  a variable 
anywhere).  The  p in  the  outer  scope  is  i n the  same  situation. 

The  definition  of  i in  the  control  expression  oftheforloop  is  an 
examp  I e of  bei  ng  abl  e to  def  i ne  a vari  abl  e exactly  at  the  poi  nt  you 
need  it  (you  can  dothisonly  in  C++).  The  scope  of  i isthe  scope  of 
the  expression  controlled  by  theforloop,  so  you  can  turn  around 
and  re-use  i in  the  next  for  loop.  This  is  a convenient  and 
commonly-used  idiom  in  C-I-+;  i istheclassicnamefor  a loop 
counter  and  you  don't  have  to  keep  inventing  new  names. 

Although  the  example  also  shows  variables  defined  within  whilo 
if,  and  switch  statements,  this  kind  of  definition  ismuch  less 
common  than  those  in  for  expressions,  possibly  because  the  syntax 
is  so  constrained.  For  example,  you  cannot  have  any  parentheses. 
That  is,  you  cannot  say: 
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while  ( (char  c = cin.getO)  !=  'q') 

The  addition  of  the  extra  parentheses  wou  id  seem  i ike  an  innocent 
and  usefui  thing  to  do,  and  because  you  cannot  use  them,  the 
resuits  are  not  what  you  might  i ike.  The  probiem  occurs  because 
'!='  has  a higher  precedence  than  '=',  so  the  chare  ends  up 
containing  a bool  converted  to  char  When  that's  printed,  on  many 
termi nai s you'i  i see  a smi  i ey-face  character. 

in  generai,you  can  consi der  the abi i ity  to  define  variabies  within 
whila  if,  and  switch  statements  as  being  therefor  compieteness, 
buttheoniy  piaceyou'reiikeiy  to  use  this  kind  of  variabie 
definition  is  in  aforioop  (where  you'ii  use  it  quite  often). 


Specifying  storage  aiiocation 

When  creating  a variabie,  you  have  a number  of  options  to  specify 
the  iifeti  me  of  the  variabie,  how  the  storage  is  aiiocated  for  that 
variabie,  and  how  the  variabie  is  treated  by  thecompiier. 

Global  variables 

Giobai  variabies  are  defined  outside  aii  function  bodies  and  are 
avaiiabieto  aii  parts  of  the  program  (even  code  in  other  fiies). 

Giobai  variabies  are  unaffected  by  scopes  and  areaiwaysavaiiabie 
(i.e.,  the  iifeti  me  of  a giobai  variabie  iastsuntii  the  program  ends),  if 
theexistenceof  a giobai  variabie  in  onefiieisdeciared  using  the 
extern  keyword  i n another  f i i e,  the  data  i s avai  i abi  e for  use  by  the 
second  fiie.  Here's  an  exampieof  the  use  of  giobai  variabies: 

//:  COS : Global . epp 
//{L}  Global2 

//  Demonstration  of  global  variables 
#lnclude  <lostream> 
using  namespace  std; 

Int  globe; 
void  f unc ( ) ; 

Int  main  ( ) { 
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globe  = 12; 

cout  <<  globe  <<  endl; 
funcO;  //  Modifies  globe 
cout  <<  globe  <<  endl; 

} ///:- 

H ere's  a fi  le  that  accesses  globe  as  an  extern: 

//:  COS : Global2 . cpp  {0} 

//  Accessing  external  global  variables 
extern  int  globe; 

//  (The  linker  resolves  the  reference) 
void  f unc  ( ) { 

globe  = 47; 

} ///:- 

Storage  for  the  variable  globe  is  created  by  the  definition  in 
GlobaLcpp  and  that  same  variable  is  accessed  by  the  code  in 
G lobal2.cpp  Si  nee  the  code  in  G lobal2.cppis  compiled  separately 
from  the  code  in  GlobaLcpp  the  compiler  must  be  informed  that 
the  vari  abl  e exi  sts  el  sew  here  by  the  deci  arati  on 

extern  int  globe; 

When  you  run  the  program,  you'll  see  that  the  cal  I tofunc(  )does 
indeed  affect  the  single  global  instance  of  globe 

In  GlobaLcpp  you  can  seethe  special  comment  tag  (which  ismy 
own  design): 

//{L}  Global2 

This  says  that  to  create  the  final  program,  the  object  file  with  the 
nameGlobal2must  be  linked  in  (there  is  no  extension  because  the 
extensi  on  names  of  object  f i I es  d iffer  from  one  system  to  the  next). 

I n G I obal  2.cpp  the  f i rst  I i ne  has  another  speci  al  comment  tag  -P 1 
which  says  "Don't  try  to  create  an  executable  out  of  this  file,  it's 
being  compiled  so  that  it  can  delinked  into  some  other  executable." 
TheExtractCode.cpRDrogram  in  Volume  2 of  this  book 
(downloadable  at  n/n/n/.6rtyce£ckef.com)  reads  these  tags  and  creates 
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theappropriatemakefileso  everything  compiles  properly  (you'll 
learn  about  makefiles  at  the  end  of  this  chapter). 

Local  variables 

Local  variables  occur  within  a scope;  they  are  "local"  to  a function. 
They  are  often  called  automat/c  variables  because  they  automatically 
come  into  being  when  the  scope  is  entered  and  automatically  go 
away  when  the  scope  closes.  The  keyword  auto  makes  this  explicit, 
but  local  variables  default  to  auto  so  it  is  never  necessary  to  declare 
something  as  an  auto. 

Register  variables 

A register  variable  is  a type  of  local  variable.  The  registerkeyword 
tel  I s the  compi  I er " M ake  accesses  to  thi  s vari  abl  e as  fast  as 
possible."  Increasing  the  access  speed  is  implementation 
dependent,  but,  as  the  name  suggests,  it  isoften  done  by  placing 
the  vari  abl  e i n a regi  ster.  There  i s no  gu  arantee  that  the  vari  abl  e 
will  be  placed  in  a register  or  even  that  the  access  speed  will 
increase.  It  Isa  hint  to  the  compiler. 

There  are  restri  cti  ons  to  the  use  of  regi stervari  abl  es.  Y ou  cannot 
take  or  compute  the  add  ress  of  a regi  stervari  abl  e.  A regi  ster 
variablecan  be  declared  only  within  a block  (you  cannot  have 
global  or  static  regi  stervar  i abl  es).  You  can,  however,  use  a register 
vari  able  as  a formal  argument  in  a function  (i.e.,  in  the  argument 
list). 

In  general,  you  shouldn'ttry  to  second-guess  the  compiler's 
optimizer,  since  it  will  probably  do  a better  job  than  you  can.  Thus, 
the  registerkeyword  is  best  avoided. 

Static 

The  static  keyword  has  several  distinct  meanings.  Normally, 
variables  defined  local  to  a function  disappear  at  the  end  of  the 
function  scope.  When  you  call  thefunction  again,  storagefor  the 
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variables  iscreated  anew  and  thevalues  are  re-initialized.  If  you 
want  a value  to  beextantthroughoutthelifeof  a program,  you  can 
define  a function's  local  variableto  bestaticand  giveitan  initial 
value.  The  initialization  is  performed  only  the  first  time  the 
function  is  cal  led,  and  the  data  retains  its  value  between  function 
calls.  Thisway,  afunction  can  "remember"  some  piece  of 
information  between  function  calls. 

You  may  wonder  why  a global  variable  isn't  used  instead.  The 
beauty  of  a stati c vari  abl  e i s that  i t i s u navai  I abl e outsi d e the  scope 
of  the  function,  so  it  can't  be  inadvertently  changed.  This  localizes 
errors. 

H ere's  an  example  of  the  use  of  static  variables: 

//:  COS : Static . cpp 

//  Using  a static  variable  in  a function 
#include  <iostream> 
using  namespace  std; 

void  f unc ( ) { 

static  int  i = 0; 

cout  <<  "i  = " <<  ++i  <<  endl; 

} 

int  main  ( ) { 

for(int  X = 0;  x < 10;  x++) 
f unc  ( ) ; 

} ///:- 

Each  timefunc( ) iscalled  in  thefor  loop,  it  prints  a different  value. 
If  the  keyword  staticis  not  used,  the  value  printed  will  always  be 
'1'. 

The  second  meaning  of  static  is  related  to  the  first  in  the 
"unavailable  outside  a certain  scope"  sense.  When  staticis  applied 
to  a function  nameortoa  vari  able  that  is  outside  of  all  functions,  it 
means  "This  name  i s u navai  I abl  e outsi  de  of  th  i s f i I e."  The  f u ncti  on 
name  or  variable  is  local  to  the  file;  we  say  it  has  file  scope.  Asa 
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demonstration,  compiling  and  linking  thefollowing  two  files  will 
cause  a linker  error: 

//:  COS : FileStatic . cpp 

//  File  scope  demonstration.  Compiling  and 
//  linking  this  file  with  FileStaticS . cpp 
//  will  cause  a linker  error 

//  File  scope  means  only  available  in  this  file: 
static  int  fs; 

int  main  ( ) { 

fs  = 1; 

} ///:- 

Even  though  the  variable  fs  is  cl  aimed  to  exist  as  an  extern  in  the 
fol  low!  ng  fi I e,  the  I i nker  won't  fi nd  it  because  it  has  been  declared 

static! n FileStaticxpp 

//:  COS : FileStaticS . cpp  {0} 

//  Trying  to  reference  fs 
extern  int  fs; 
void  f unc ( ) { 

fs  = 100; 

} ///:- 

Thestaticspecifier  may  also  be  used  insidea  class  This 
explanation  will  bedelayed  until  you  learn  to  create  cl  asses,  later  in 
the  book. 

extern 

The  extern  keyword  has  already  been  briefly  described  and 
demonstrated . 1 1 tel  I s the  compi  I er  that  a vari  abl  e or  a fu ncti  on 
exists,  even  if  the  compiler  hasn't  yet  seen  it  in  the  file  currently 
being  compi  led.  This  vari  able  or  function  may  bedefined  in 
another  file  or  further  down  in  the  current  file.  As  an  example  of 
the  latter: 

//:  COS :Forward. cpp 

//  Forward  function  & data  declarations 
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#include  <iostream> 
using  namespace  std; 


//  This  is  not  actually  external,  but  the 
//  compiler  must  be  told  it  exists  somewhere: 
extern  int  i; 
extern  void  func(); 
int  main  ( ) { 

i = 0; 
f unc  ( ) ; 

} 

int  i;  //  The  data  definition 
void  f unc ( ) { 

i + + ; 

cout  <<  i; 

} ///:- 

When  the  compiler  encounters  the  declaration  'extern  inti,  it 
knows  that  the  definition  fori  must  exist  somewhereas  a global 
variable.  When  the  compiler  reaches  the  definition  of  i,  no  other 
declaration  is  visible,  so  it  knows  it  has  found  thesamei  declared 
earlier  in  the  file.  If  you  were  to  definei  as  static  you  would  be 
tel  I ing  the  compiler  that  i is  defined  globally  (via  the  extern),  but  it 
also  has  file  scope  (via  the  static),  so  the  compiler  will  generate  an 
error. 

Linkage 

To  understand  thebehavior  of  C and  C++ programs,  you  need  to 
know  about  linkage.  In  an  executing  program,  an  identifier  is 
represented  by  storage  in  memory  that  holds  a variable  or  a 
compiled  function  body.  Linkage  describes  this  storage  as  it  is  seen 
by  the  I inker.  There  are  two  types  of  linkage:  internal  linkagear\6 
external  linkage. 

I nternal  I inkage  means  that  storage  is  created  to  represent  the 
i d entif  i er  on  I y for  the  f i I e bei  ng  compi  I ed . Other  f i I es  may  use  the 
same  identifier  name  with  internal  linkage,  or  for  a global  variable, 
and  no  conflicts  will  be  found  by  the  linker- separate  storage  is 
created  for  each  identifier.  Internal  I inkage  is  specified  by  the 
keyword  staticin  C and  C++. 
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External  I i nkage  means  that  a si ngl e piece  of  storage  i s created  to 
represent  the  identifier  for  all  files  being  compiled.  The  storage  is 
created  once,  and  the  I i nker  must  resolve  al  I other  references  to  that 
storage.  Global  variables  and  function  names  have  external  linkage. 
These  are  accessed  from  other  files  by  declaring  them  with  the 
keyword  extern.  Variables  defined  outside  all  functions  (with  the 
exception  of  constin  C++)  and  function  definitions  default  to 
external  linkage.  You  can  specifically  force  them  to  have  internal 
linkage  using  the  static  keyword.  You  can  explicitly  state  that  an 
identifier  has  external  linkage  by  defining  it  with  the  extern 
keyword.  Defining  a variable  or  function  with  extern  is  not 
necessary  in  C,  but  it  is  sometimes  necessary  for  constin  C++. 

Automatic  (local)  variablesexist  only  temporarily,  on  the  stack, 
while  a function  is  being  called.  The  linker  doesn't  know  about 
automatic  variables,  and  so  these  have  no  linkage. 

Constants 

In  old  (pre-Standard)  C,  if  you  wanted  to  make  a constant,  you  had 
to  use  the  preprocessor: 

I #define  PI  3.14159 

Everywhere  you  used  PI,  thevalue  3.14159  was  substituted  by  the 
preprocessor  (you  can  still  use  this  method  in  C and  C++). 

When  you  use  the  preprocessor  to  create  constants,  you  place 
control  of  those  constants  outsidethe  scope  of  thecompiler.  No 
type  checking  is  performed  on  the  name  PI  and  you  can't  take  the 
address  of  PI  (so  you  can't  pass  a pointer  or  a reference  to  PI).  PI 
cannot  be  a vari abl  e of  a user-defi  ned  type.  The  meani  ng  of  PI  I asts 
from  the  point  it  is  defined  to  the  end  of  the  file;  the  preprocessor 
doesn't  recognize  scoping. 

C ++  i ntrod uces  the  concept  of  a named  constant  that  i s just  I i ke  a 
variable,  except  that  its  value  cannot  be  changed.  The  modifier 
consttel  Is  the  compiler  that  a name  represents  a constant.  Any  data 
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type,  built-in  or  user-defined,  may  be  defined  as  const  If  you 
define  something  asconstand  then  attempt  to  modify  it,  the 
compiler  will  generate  an  error. 

You  mustspecify  thetypeof  aconst  I ike  this: 

const  int  x = 10; 

In  Standard  C and  C++,  you  can  usea  named  constant  in  an 
argument  list,  even  if  the  argument  it  fills  is  a pointer  or  a reference 
(i.e.,  you  cantaketheaddressof  aconst).  A consthas a scope,  just 
likea  regular  variable,  so  you  can  "hide"  a constinside  a function 
and  be  sure  that  the  name  wi  1 1 not  affect  the  rest  of  the  program. 

The constwas taken  from  C-H-and  incorporated  into  Standard  C, 
albeit  quite  differently.  In  C,  the  compiler  treats  a constjust  likea 
variable  that  has  a special  tag  attached  that  says  "Don't  change 
me."  When  you  define  a constin  C,  the  compiler  creates  storage  for 
it,  so  if  you  define  more  than  oneconstwith  the  same  name  in  two 
different  files  (or  put  the  definition  in  a header  file),  the  linker  will 
generate  error  messages  about  confl  lets.  The  i ntended  use  of  const 
in  C is  quite  different  from  its  intended  use  in  C-H-(in  short,  it's 
nicer  in  C-H-). 

Constant  values 

In  C-H-,  a constmust  always  have  an  initialization  value  (in  C,  this 
i s not  true).  Constant  val  ues  for  bu i It-i  n types  are  expressed  as 
decimal,  octal,  hexadecimal,  or  floating-point  numbers  (sadly, 
binary  numbers  were  not  considered  important),  or  as  characters. 

I n the  absence  of  any  other  clues,  the  compiler  assumes  a constant 
value  is  a decimal  number.  The  numbers  47,  0,  and  1101  are  all 
treated  as  decimal  numbers. 

A constant  value  with  a leading  0 is  treated  as  an  octal  number 
(base  8).  Base  8 numbers  can  contain  only  digits  0-7;  the  compiler 
flags  other  digits  as  an  error.  A legitimate  octal  number  is  017  (15  in 
base  10). 
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A constant  value  with  a leading  Ox  istreated  as  a hexadecimal 
number  (base  16).  Base  16  numbers  contain  the  digits  0-9  and  a-f  or 
A-F.  A legitimate  hexadecimal  number  is Oxlfe (510  in  base  10). 

Floating  point  numbers  can  contain  decimal  points  and  exponential 
powers  (represented  by  e,  which  means  "10  to  the  power  of").  Both 
thedecimal  point  and  thee  are  optional.  If  you  assign  aconstantto 
a f I oati  ng-poi  nt  vari  abl  e,  the  compi  I er  w i 1 1 take  the  constant  val  ue 
and  convert  it  to  a floating-point  number  (this  process  is  one  form 
of  what's  cal  led  implicit  type  con  version).  However,  itisagood  idea 
to  use  either  a decimal  point  or  an  eto  remind  the  reader  that  you 
are  using  a floating-point  number;  some  older  compilers  also  need 
the  hint. 

Legitimate  floating-point  constant  values  are:  le4, 1.0001, 47.0,  0.0, 
and  -1.159e-77.  You  can  add  suffixestoforcethetypeof  floating- 
point number:  f or  F forces  a float  L or  I forces  a long  double; 
otherwisethe  number  will  be  a double 

Character  constants  are  characters  surrounded  by  single  quotes,  as: 
'A',  'O', ' '.  Noticethereisa  big  difference  between  the  character  'O' 
(ASCII  96)  and  thevalueO.  Special  characters  are  represented  with 
the  "backslash  escape":  '\  n'  (newline),  '\  t (tab),  '\  \ ' (backslash), 

'\  r'  (carriage  return),  '\ "'  (double quotes),  '\  " (single quote),  etc. 
You  can  also  express  char  constants  in  octal:  '\  17  or  hexadecimal: 

'\  xff. 

volatile 

Whereas  the  qualifierconsttel  Is  the  compiler  "This  never  changes" 
(which  allows  the  compiler  to  perform  extra  optimizations),  the 
qualifier  volatiletellsthe compiler  "You  never  know  when  this  will 
change,"  and  prevents  the  compiler  from  performing  any 
optimizations  based  on  the  stability  of  that  variable.  Use  this 
keyword  when  you  read  somevalueoutsidethe  control  of  your 
code,  such  asa  register  in  a piece  of  communication  hardware.  A 
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volatilevariable  is  always  read  whenever  its  value  is  required, 
even  if  it  was  just  read  the  line  before. 

A special  case  of  some  storage  bei  ng  "outside  the  control  of  your 
code”  is  in  a multithreaded  program.  If  you're  watching  a 
particular  flag  that  is  modified  by  another  thread  or  process,  that 
flag  should  bevolatileso  the  compiler  doesn't  make  the 
assumption  that  it  can  optimize  away  multiple  reads  of  the  flag. 

Notethatvolatilemay  have  no  effect  when  a compiler  is  not 
optimizing,  but  may  prevent  critical  bugs  when  you  start 
optimizing  the  code  (which  iswhen  the  compiler  will  begin  looking 
for  redundant  reads). 

Theconstand  volati I ekey words  will  befurther  illuminated  in  a 
later  chapter. 


Operators  and  their  use 

This  section  covers  all  the  operators  i n C and  C++. 

A 1 1 operators  produce  a val  ue  from  thei  r operands.  Thi s val  ue  i s 
produced  without  modifying  the  operands,  except  with  the 
assignment,  increment,  and  decrement  operators.  Modifying  an 
operand  is  cal  led  a side  effect.  The  most  common  use  for  operators 
that  mod  ify  thei  r operands  i s to  generate  the  si  de  effect,  but  you 
should  keep  in  mind  that  the  value  produced  is  aval  I able  for  your 
usejustasin  operators  without  side  effects. 

Assignment 

Assignment  is  performed  with  the  operator  =.  It  means  "Takethe 
right-hand  side  (often  called  the  rvalue)  and  copy  it  into  the  left- 
hand  side  (often  called  the  lvalue).”  An  rvalue  is  any  constant, 
variable,  or  expression  that  can  produce  a value,  but  an  lvalue  must 
be  a distinct,  named  variable  (that  is,  there  must  be  a physical  space 
in  which  to  storedata).  For  instance,  you  can  assign  a constant 


168 


Thinking  in  C+  + 


www.BruceEckel.com 


valueto  a variable  (A  =4il,  but  you  cannot  assign  anything  to 
constant  value  - it  cannot  bean  lvalue  (you  can'tsay  4 = Ai). 

Mathematical  operators 

The  basi  c mathennati  cal  operators  are  the  same  as  the  ones  aval  I abl  e 
in  most  programming  languages:  addition  (+),  subtraction  (-), 
division  (/),  multiplication  (*),  and  modulus  (%;  this  produces  the 
remainder  from  integer  division).  Integer  division  truncates  the 
result  (it  doesn't  round).  The  modulus  operator  cannot  be  used 
with  floating-point  numbers. 

C and  C-H-also  use  a shorthand  notation  to  perform  an  operation 
and  an  assignment  at  the  same  time.  This  is  denoted  by  an  operator 
followed  by  an  equal  sign,  and  is  consistent  with  all  the  operators 
in  the  language  (whenever  it  makes  sense).  For  example,  to  add  4to 
thevariablexand  assign  x to  the  result,  you  say:  x +=  4; 

This  exampi e shows  the  use  of  the  mathemati cal  operators: 

//:  COS :Mathops . cpp 
//  Mathematical  operators 
#include  <iostream> 
using  namespace  std; 


//  A macro  to  display  a string  and  a value. 
#define  PRINT (SIR,  VAR)  \ 

cout  <<  STR  " = " <<  VAR  <<  endl 

int  main  ( ) { 

int  i,  j,  k; 

float  u,  V,  w;  //  Applies  to  doubles,  too 
cout  <<  "enter  an  integer: 
cin  >>  j; 

cout  <<  "enter  another  integer: 
cin  >>  k; 

PRINT ("j", j) ; PRINT ("k",k) ; 
i = j + k;  PRINT ("j  + k",i); 

i = j - k;  PRINT ("j  - k",i); 

i = k / j;  PRINT ("k  / j",i); 

i = k * j;  PRINT ("k  * j",i); 
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i = k % j;  PRINT ("k  % 

//  The  following  only  works  with  integers: 
j %=  k;  PRINT ("j  %=  k",  j) ; 
cout  <<  "Enter  a floating-point  number: 
cin  >>  v; 

cout  <<  "Enter  another  floating-point  number:"; 
cin  >>  w; 

PRINT ("v",v) ; PRTNT ("w", w) ; 
u = V + w;  PRINT ("v  + w",  u) ; 

u = V - w;  PRINT ("v  - w",  u) ; 

u = V * w;  PRTNT ("v  * w",  u) ; 

u = V / w;  PRINT ("v  / w",  u) ; 

//  The  following  works  for  ints,  chars, 

//  and  doubles  too: 

PRINT ("u",  u) ; PRINT ("v",  v) ; 


u 

+=  v; 

PRTNT ("u 

+=  v". 

u) 

r 

u 

-=  v; 

PRINT ("u 

-=  V", 

u) 

f 

u 

*=  v; 

PRTNT ("u 

*=  v". 

u) 

t 

u 

/=  v; 

PRINT ("u 

/=  V", 

u) 

t 

} ///:- 

The  rvalues  of  al  I the  assignments  can,  of  course,  be  much  more 
complex. 

I ntroduction  to  preprocessor  macros 

Notice  the  use  of  the  macro  PRINT(  )to  save  typing  (and  typing 
errors!).  Preprocessor  macros  are  traditionally  named  with  all 
uppercase  letters  so  they  stand  out- you'll  learn  later  that  macros 
can  quickly  become  dangerous  (and  they  can  also  be  very  useful). 

The  argu  ments  I n the  parenthesi zed  1 1 st  fol  I ow  I ng  the  macro  name 
are  substituted  in  all  the  code  fol  I owing  the  closing  parenthesis. 
The  preprocessor  removes  the  name  PRINT  and  substitutes  the 
code  wherever  the  macro  is  cal  led,  so  the  compiler  cannot  generate 
any  error  messages  usi  ng  the  macro  name,  and  it  doesn't  do  any 
type  check!  ng  on  the  argu  ments  (the  I after  can  be  benef  I cl  al , as 
shown  I n the  debuggi  ng  macros  at  the  end  of  the  chapter). 
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Relational  operators 

Relational  operators  establish  a relationship  between  the  values  of 
the  operands.  They  produce  a Boolean  (specified  with  the  bool 
keyword  in  C++)  trueif  the  relationship  istrue,  and  falseif  the 
relationship  is  false.  The  relational  operators  are:  less  than  (<), 
greater  than  (>),  I ess  than  or  equal  to  (<=),  greater  than  or  equal  to 
(>=),  equivalent  (==),  and  not  equivalent  (!=).  They  may  be  used 
with  all  built-in  data  types  in  C and  C-H-.  They  may  be  given 
special  definitions  for  user-defined  data  types  in  C-H-(you'll  learn 
about  this  in  Chapter  12,  which  covers  operator  overloading). 

Logical  operators 

The  logical  operators  and  (&&)  and  or(|  | ) produce  a true  or  false 
based  on  the  logical  relationship  of  its  arguments.  Remember  that 
in  C and  C++,  a statement  istrueif  it  has  a non-zero  value,  and 
falseif  it  has  a value  of  zero.  If  you  printabool,  you'll  typically  see 
a '1'  for  trueand  '0'  for  false 

This  example  uses  the  relational  and  logical  operators: 

//:  COS : Boolean . cpp 

//  Relational  and  logical  operators. 

#include  <iostreain> 
using  namespace  std; 


int  main  ( ) 

{ 

int 

i/  j; 

cout 

<< 

"Enter 

an 

integer : 

»? 

cin 

>>  i 

r 

cout 

<< 

"Enter 

another 

integer 

. »T 

f 

cin 

» j 

r 

cout 

<< 

"i 

> j 

is 

" << 

(i  > 

j) 

<< 

endl ; 

cout 

<< 

"i 

< j 

is 

" << 

(i  < 

j) 

<< 

endl ; 

cout 

<< 

"i 

V 

II 

LJ. 

is 

" << 

(i 

>= 

j) 

<< 

endl ; 

cout 

<< 

"i 

A 

II 

LJ. 

is 

" << 

(i 

<= 

j) 

<< 

endl ; 

cout 

<< 

"i 

==  j 

is 

" << 

(i 

== 

j) 

<< 

endl ; 

cout 

<< 

"i 

!=  j 

is 

" << 

(i 

1 = 

j) 

<< 

endl ; 

cout 

<< 

"i 

&&  j 

is 

" << 

(i 

&& 

j) 

<< 

endl ; 

cout 

<< 

"i 

1 1 j 

is 

" << 

(i 

1 1 

j) 

<< 

endl ; 
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cout  <<  " (i  < 10)  &&  (j  < 10)  is  " 

<<  ( (i  < 10)  &&  (j  < 10))  <<  endl; 

} ///:- 

You  can  replace  the  definition  forintwith  floator  doublein  the 
program  above.  Be  aware,  however,  that  the  comparison  of  a 
floating-point  number  with  the  value  of  zero  is  strict;  a number  that 
is  the  tiniest  fraction  different  from  another  number  isstill  "not 
equal."  A floating-point  number  that  isthe  tiniest  bit  abovezero  is 
still  true. 


Bitwise  operators 

The  bitwise  operators  allow  you  to  manipulate  individual  bits  in  a 
number  (si  nee  floating  point  values  use  a special  internal  format, 
the  bitwise  operators  work  only  with  integral  types:  char,  inland 
long).  Bitwise  operators  perform  Boolean  algebra  on  the 
corresponding  bits  in  the  arguments  to  produce  the  result. 

The  bitwise  and  operator  (&)  produces  a one  in  the  output  bit  if 
both  input  bits  are  one;  otherwise  it  produces  a zero.  The  bitwise  or 
operator  (|  ) produces  a one  in  the  output  bit  if  either  input  bit  is  a 
one  and  produces  a zero  only  if  both  input  bits  are  zero.  The 
bitwise  exclusive  or,  or  xor  ('')  produces  a one  in  the  output  bit  if  one 
or  the  other  input  bit  is  a one,  but  not  both.  The  bitwise  not  (~,  also 
called  the  ones  complement  operator)  is  a unary  operator  - it  only 
takes  one  argument  (al  I other  bitwise  operators  are  binary 
operators).  Bitwise  not  produces  the  opposite  of  the  input  bit  - a 
one  if  the  input  bit  is  zero,  a zero  if  the  input  bit  is  one. 

Bitwise  operators  can  be  combined  with  the  = sign  to  unite  the 
operation  and  assignment:  &=,  | =,and  ''=areall  legitimate 
operations  (since  ~ is  a unary  operator  it  cannot  be  combined  with 
the  = sign). 
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Shift  operators 

The  shift  operators  also  manipulate  bits.  The  left-shift  operator  («) 
produces  the  operand  totheleft  of  the  operator  shifted  to  the  left 
by  the  number  of  bits  specified  after  the  operator.  The  right-shift 
operator  (»)  produces  the  operand  to  the  left  of  the  operator 
shifted  to  the  right  by  the  number  of  bits  specified  after  the 
operator.  If  the  value  after  the  shift  operator  is  greater  than  the 
number  of  bits  in  the  left-hand  operand,  the  result  is  undefined.  If 
the  left-hand  operand  is  unsigned,  the  right  shift  is  a logical  shift  so 
the  upper  bits  will  be  filled  with  zeros.  If  the  left-hand  operand  is 
signed,  the  right  shift  may  or  may  not  be  a logical  shift  (that  is,  the 
behavior  is  undefined). 

Shifts  can  be  combined  with  the  equal  sign  («=and  »=).The 
lvalue  is  replaced  by  the  lvalue  shifted  by  the  rvalue. 

What  follows  is  an  examplethat  demonstrates  the  use  of  all  the 
operators  involving  bits.  First,  here's  a general -purpose function 
that  pri  nts  a byte  i n bi  nary  format,  created  separatel y so  that  it  may 
be easi I y reu sed . Th e h ead erfiledeclaresthefunction: 

//:  COS : printBinary . h 

//  Display  a byte  in  binary 

void  printBinary (const  unsigned  char  val); 

///:- 

H ere's  the  i mpl  ementati  on  of  the  f u ncti  on : 

//:  COS : printBinary . cpp  {0} 

#include  <iostream> 

void  printBinary (const  unsigned  char  val)  { 
for(int  i = 7;  i >=  0;  i — ) 
if (val  & ( 1 <<  i ) ) 

std : : cout  <<  " 1 " ; 
else 

std : : cout  <<  " 0 " ; 

} ///:- 

The  printBinary!  )function  takes  a single  byte  and  displays  it  bit- 
by-bit.  The  expression 
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produces  a one  in  each  successive  bit  position;  in  binary:  00000001, 
00000010,  etc.  If  this  bit  is  bitwise  an ded  with  val  and  the  result  is 
nonzero,  it  means  there  was  a one  in  that  position  in  val. 

Finally,  the  function  is  used  in  the  example  that  shows  the  bit- 
manipulation  operators: 

//:  COS : Bitwise . cpp 
//{L}  printBinary 

//  Demonstration  of  bit  manipulation 
#include  "printBinary . h" 

#include  <iostream> 
using  namespace  std; 

//  A macro  to  save  typing: 

#define  PR(STR,  EXPR)  \ 

cout  <<  STR;  printBinary (EXPR) ; cout  <<  endl; 

int  main  ( ) { 

unsigned  int  getval; 
unsigned  char  a,  b; 

cout  <<  "Enter  a number  between  0 and  255: 
cin  >>  getval;  a = getval; 

PR("a  in  binary:  ",  a); 

cout  <<  "Enter  a number  between  0 and  255:  "; 
cin  >>  getval;  b = getval; 

PR("b  in  binary:  ",  b) ; 

PR("a  I b = ",  alb); 

PR ( "a  & b = ",  a & b)  ; 

PR("a  " b = ",  a " b)  ; 

PR("~a  = ",  ~a); 

PR("~b  = ",  ~b)  ; 

//  An  interesting  bit  pattern: 
unsigned  char  c = 0x5A; 

PR("c  in  binary:  ",  c)  ; 

a I = c; 

PR("a  1=  c;  a = ",  a); 
b &=  c; 

PR("b  &=  c;  b = ",  b)  ; 
b a; 

PR("b  "=  a;  b = ",  b)  ; 

} ///:- 
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Once  again,  a preprocessor  macro  is  used  to  save  typing.  It  prints 
the  string  of  your  choice,  then  the  binary  representation  of  an 
expression,  then  a newline. 

In  main( ) the  variables  are  unsigned  This  is  because,  in  general, 
you  don't  want  signs  when  you  are  working  with  bytes.  An  int 
must  be  used  instead  of  a char  for  getval  because  the  "cin  »" 
statement  will  otherwisetreatthefirst  digit  as  a character.  By 
assigning  getval  to  a and  b,  the  value  is  converted  to  a single  byte 
(by  truncating  it). 

The  « and  » provide  bit-shifting  behavior,  but  when  they  shift 
bits  off  the  end  of  the  number,  those  bits  are  lost  (it's  commonly 
said  that  they  fall  into  the  mythical  bit  bucket,  a place  where 
discarded  bits  end  up,  presumably  so  they  can  be  reused...).  When 
manipulating  bits  you  can  also  perform  rotation,  which  means  that 
the  bits  that  fall  off  one  end  areinserted  backattheotherend,asif 
they're  being  rotated  around  a loop.  Even  though  most  computer 
processors  provide  a machine-level  rotate  command  (so  you'll  see 
it  in  the  assembly  language  for  that  processor),  there  is  no  direct 
support  for  "rotate"  in  C or  C-H-.  Presumably  the  designers  of  C felt 
justified  in  leaving  "rotate"  off  (aiming,  as  they  said,  for  a minimal 
language)  because  you  can  build  your  own  rotate  command.  For 
example,  here  are  functions  to  perform  left  and  right  rotations: 

//:  COS : Rotation . cpp  {0} 

//  Perforin  left  and  right  rotations 

unsigned  char  rol (unsigned  char  val)  { 
int  highbit; 

if (val  & 0x80)  //  0x80  is  the  high  bit  only 

highbit  = 1; 
else 

highbit  = 0; 

//  Left  shift  (bottom  bit  becomes  0) : 
val  <<=  1; 

//  Rotate  the  high  bit  onto  the  bottom: 
val  I = highbit ; 
return  val; 
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} 

unsigned  char  ror (unsigned  char  val)  { 
int  lowbit; 

if (val  & 1)  //  Check  the  low  bit 
lowbit  = 1; 
else 

lowbit  = 0; 

val  >>=  1;  //  Right  shift  by  one  position 
//  Rotate  the  low  bit  onto  the  top: 
val  1=  (lowbit  <<  7); 
return  val; 

} ///:- 

Try  using  these  functions  in  Bitwise.cpp  Noti  ce  the  definitions  (or 
at  least  declarations)  of  rol(  )and  ror(  )must  be  seen  by  the 
compiler  in  Bitwisexppbeforethefunctions  are  used. 

The  bitwise  functions  are  generally  extremely  efficient  to  use 
becausethey  translate  directly  into  assembly  language  statements. 
Sometimes  a si ngleC  or  C++statement  will  generatea  single  line 
of  assembly  code. 

Unary  operators 

Bitwise  not  isn't  the  only  operator  that  takes  a single  argument.  Its 
companion,  thelogical  not  (!),  will  take  a true  value  and  producea 
falsevalue.  The  unary  minus(-)  and  unary  plus(+)  are  the  same 
operators  as  binary  minus  and  plus;  thecompiler  figures  out  which 
usage  is  intended  by  the  way  you  write  the  express!  on.  For 
i nstance,  the  statement 

I ^ ^ 

has  an  obvi  ous  meani  ng.  The  compi  I er  can  fi  gu re  out: 

I X = a * -b; 

but  the  reader  might  get  confused,  so  it  is  safer  to  say: 

I X = a * (~b)  ; 
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The  unary  minus  producesthe  negative  of  the  value.  Unary  plus 
provides  symmetry  with  unary  minus,  although  it  doesn't  actually 
do  anything. 

The  increment  and  decrement  operators  (++  and  --)  were 
introduced  earlier  in  this  chapter.  These  are  the  only  operators 
other  than  those  involving  assignment  that  have  side  effects.  These 
operators  increase  or  decrease  the  variable  by  one  unit,  although 
"unit"  can  have  different  meanings  according  to  the  data  type -this 
is  especially  true  with  pointers. 

The  last  unary  operators  are  the  address-of(&),  dereference  (*  and  - 
>),  and  cast  operators  in  C and  C++,  and  new  and  deletein  C++. 
Address-of  and  dereference  are  used  with  pointers,  described  in 
this  chapter.  Casting  is  described  later  in  this  chapter,  and  new  and 
del eteare  introduced  in  Chapter  4. 

The  ternary  operator 

The  ternary  if-elseis  unusual  because  it  has  three  operands.  It  is 
truly  an  operator  becauseit  produces  a value,  uni  ike  the  ordinary 
if-elsestatement.  It  consists  of  three  expressions:  ifthe first 
expressi  on  (fol  I owed  by  a ?)  eval  uates  to  true  the  expressi  on 
following  the?  is  evaluated  and  its  result  becomes  the  value 
produced  by  the  operator.  If  the  first  expressi  on  is  false  the  third 
expression  (following  a :)  is  executed  and  its  result  becomes  the 
value  produced  by  the  operator. 

The  conditional  operator  can  be  used  for  its  side  effects  or  for  the 
value  it  produces.  Here's  a codefragment  that  demonstrates  both: 

I a = — b ? b : (b  = -99) ; 

H ere,  the  cond  i ti  onal  prod uces  the  rval  ue.  a i s assi gned  to  the  val  ue 
of  b ifthe  result  of  decrementing  b is  nonzero.  If  b becamezero,  a 
and  b are  both  assigned  to  -99.  b is  always  decremented,  but  it  is 
assigned  to  -99  only  if  the  decrement  causes  b to  become  0.  A 


3:  The  C in  C+  + 


177 


similar  statement  can  be  used  without  the"a  ="  just  for  its  side 
effects: 


— b ? b : (b  = -99) ; 

Here  the  second  B is  superfluous,  si  nee  the  value  produced  by  the 
operator  is  unused.  An  expression  is  required  between  the?  and 
In  this  case,  the  express!  on  could  simply  be  a constant  that  might 
make  the  code  run  a bit  faster. 


The  comma  operator 

The  comma  is  not  restricted  to  separating  variable  names  in 
multi  pie  definitions,  such  as 

I int  i,  j,  k; 

Of  course,  it's  also  used  in  function  argument  lists.  However,  it  can 
also  be  used  as  an  operator  to  separate  expressions  - in  this  case  it 
produces  only  the  value  of  the  last  expression.  A 1 1 the  rest  of  the 
expressions  in  the  comma-separated  list  are  evaluated  only  for  their 
side  effects.  This  example  increments  a list  of  variables  and  uses  the 
I ast  one  as  the  rval  u e: 


//:  COS : CommaOperator . epp 
#include  <iostream> 
using  namespace  std; 
int  main  ( ) { 

int  a = 0,  b = 1,  c = 2,  d = 3,  e = 4; 
a = (b++,  C++,  d++,  e++) ; 

cout  <<  "a  = " <<  a <<  endl; 

//  The  parentheses  are  critical  here.  Without 
//  them,  the  statement  will  evaluate  to: 

(a  = b++) , C++,  d++,  e++; 

cout  <<  "a  = " <<  a <<  endl; 

} ///:- 

In  general,  it's  best  to  avoid  using  the  comma  as  anything  other 
than  a separator,  since  people  are  not  used  to  seeing  it  as  an 
operator. 
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Common  pitfalls  when  using  operators 

As  illustrated  above,  one  of  the  pitfallswhen  using  operators  is 
tryi  ng  to  get  away  without  parentheses  when  you  are  even  the  I east 
bituncertain  about  how  an  expression  will  evaluate  (consult  your 
local  C manual  for  the  order  of  expression  evaluation). 

Another  extremely  common  error  looks  I ike  this: 

//:  COS : Pitfall . cpp 
//  Operator  mistakes 

int  main  ( ) { 

int  a = 1,  b = 1; 
while (a  = b)  { 

//  


I } ///:- 

The  Statement  a = bwill  always  evaluate  to  true  when  b isnon- 
zero.  The  vari  abl  e a i s assi  gned  to  the  val  ue  of  b,  and  the  val  ue  of  b 
is  also  produced  by  the  operator  =.  In  general,  you  want  to  use  the 
equivalence  operator  ==  inside  a conditional  statement,  not 
assignment.  This  one  bites  a lot  of  programmers  (however,  some 
compilers  will  point  out  the  problem  to  you,  which  is  helpful). 

A similar  problem  is  using  bitwise  and  and  or  instead  of  their 
logical  counterparts.  Bitwise  and  and  or  use  one  of  the  characters  (& 
or  I ),  while  logical  andand  or  use  two  (&&  and  | | ).  Just  as  with  = 
and  ==,  it'seasy  to  just  type  one  character  instead  of  two.  A useful 
mnemoni  c devi  ce  i s to  observe  that " Bits  are  smal  I er,  so  they  don't 
need  as  many  characters  in  their  operators." 

Casting  operators 

Theword  cast  is  used  in  the  sense  of  "casting  into  a mold."  The 
compiler  will  automatically  changeonetypeof  data  into  another  if 
it  makes  sense.  For  instance,  if  you  assign  an  integral  value  to  a 
floating-pointvariable,  the  compiler  will  secretly  call  afunction  (or 
more  probably,  i nsert  code)  to  convert  the  intto  a float  Casti  ng 
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allows  you  to  make  this  type  conversion  explicit,  or  to  force  it  when 
it  wouldn't  normally  happen. 

To  perform  a cast,  putthedesired  data  type  (including  all 
modifiers)  inside  parentheses  to  the  left  of  the  value.  This  value  can 
be  a variable,  a constant,  the  value  produced  by  an  expression,  or 
the  return  value  of  a function.  Here's  an  example: 

//:  COS : SimpleCast . cpp 
int  main  ( ) { 

int  b = 200; 

unsigned  long  a = (unsigned  long  int)b; 

} ///:- 

Casting  is  powerful,  but  it  can  cause  headaches  because  in  some 
situations  it  forces  the  compiler  to  treat  data  as  if  it  were  (for 
instance)  larger  than  it  really  is,  so  it  will  occupy  morespacein 
memory;  this  can  trample  over  other  data.  This  usual  ly  occurs 
when  casting  pointers,  not  when  making  simple  casts  I ike  the  one 
shown  above. 

C++ has  an  additional  casting  syntax,  which  follows  the  function 
call  syntax.  This  syntax  puts  the  parentheses  around  the  argument, 

I ike  a function  call,  rather  than  around  the  data  type: 

//:  COS : FunctionCallCast . cpp 
int  main  ( ) { 

float  a = float  (200); 

//  This  is  equivalent  to: 
float  b = (float)200; 

} ///:- 

Of  course  in  the  case  above  you  wouldn't  really  need  a cast;  you 
could  just  say  200f  (i  n effect,  that's  typical  I y what  the  compi  ler  will 
do  for  the  above  expression).  Casts  are  generally  used  instead  with 
variables,  rather  than  constants. 
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C++  explicit  casts 

Casts  should  be  used  carefully,  because  what  you  are  actually 
doing  is  saying  to  the  compiler  "Forget  type  checking  - treat  it  as 
this  other  type  instead."  That  is,  you're  introducing  a hole  in  the 
C++ type  system  and  prevent!  ng  the  compi  I er  from  tel  I i ng  you  that 
you'redoing  something  wrong  with  a type.  What's  worse,  the 
compiler  believes  you  implicitly  and  doesn't  perform  any  other 
checking  to  catch  errors.  Once  you  start  casting,  you  open  yourself 
up  for  all  kinds  of  problems.  In  fact,  any  program  that  uses  a lot  of 
casts  should  be  viewed  with  suspicion,  no  matter  how  much  you 
are  told  it  simply  "must"  bedonethat  way.  In  general,  casts  should 
be  few  and  isolated  to  the  solution  of  very  specific  problems. 

Once  you  understand  this  and  are  presented  with  a buggy 
program,  yourfirst  inclination  may  be  to  look  for  casts  as  culprits. 
But  how  do  you  I ocateC-style  casts?  They  are  simply  type  names 
inside  of  parentheses,  and  if  you  start  hunting  for  such  things  you'll 
discover  that  it's  often  hard  to  distinguish  them  from  the  rest  of 
your  code. 

Standard  C++ includes  an  explicit  cast  syntax  that  can  be  used  to 
completely  replace  the  old  C-style  casts  (of  course,  C-stylecasts 
cannot  be  outlawed  without  breaking  code,  but  compiler  writers 
could  easily  flag  old-style  casts  for  you).  Theexplicit  cast  syntax  is 
such  that  you  can  easi  ly  fi  nd  them,  as  you  can  see  by  thei  r names: 


static_cast 

For  "well-behaved"  and 
"reasonably  well-behaved"  casts, 
including  things  you  might  now 
do  without  a cast  (such  as  an 
automatic  type  conversion). 

con  st_  cast 

To  cast  away  constand/  or 

volatile 

reinterpret_cast 

To  cast  to  a completely  different 
meaning.  The  key  is  that  you'll 
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need  to  cast  back  to  the  original 
type  to  use  it  safely.  The  type  you 
cast  to  is  typically  used  only  for 
bit  twiddling  or  some  other 
mysterious  purpose.  This  is  the 
most  dangerous  of  al  1 the  casts. 

dynamic_cast 

For  type-safe  downcasting  (this 
cast  will  bedescribed  in  Chapter 
15). 

The  first  three  explicit  casts  will  be  described  more  completely  in 
thefollowing  sections,  whilethe  last  one  can  be  demonstrated  only 
after  you've  learned  more,  in  Chapter  15. 

static_cast 

A static_  casts  used  for  all  conversionsthat  are  well-defined.  These 
include"safe"  conversions  that  the  compiler  would  allow  you  to  do 
without  a cast  and  less-safe  conversions  that  are  nonetheless  wel  I- 
defined.  The  types  of  conversions  covered  by  static_castnclude 
typical  castless  conversions,  narrowing  (information-losing) 
conversions,  forcing  a conversion  from  a void*  implicit  type 
conversions,  and  static  navigation  of  class  hierarchies  (si  nee  you 
haven't  seen  classes  and  inheritance  yet,  this  last  topic  will  be 
delayed  until  Chapter  15): 

//:  COS : static_cast . epp 
void  f unc  ( int ) { } 

int  main  ( ) { 

int  i = 0x7fff;  //  Max  pos  value  = 32767 
long  1; 
float  f; 

//  (1)  Typical  castless  conversions: 

1 = 1; 
f = 1; 

/ / Also  works : 

1 = static_cast<long> (1)  ; 
f = static_cast<f loat> (1)  ; 
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//  (2)  Narrowing  conversions: 

i = 1;  //  May  lose  digits 

i = f;  //  May  lose  info 

//  Says  "I  know,"  eliminates  warnings: 

i = static_cast<int>  (1) ; 

i = static_cast<int>  (f ) ; 

char  c = static_cast<char>  (i) ; 

//  (3)  Forcing  a conversion  from  void*  : 

void*  vp  = &i; 

//  Old  way  produces  a dangerous  conversion: 
float*  fp  = (float*)vp; 

//  The  new  way  is  equally  dangerous: 
fp  = static_cast<f loat*> (vp)  ; 

//  (4)  Implicit  type  conversions,  normally 

//  performed  by  the  compiler: 
double  d = 0.0; 

int  X = d;  //  Automatic  type  conversion 
X = static_cast<int> (d) ; //  More  explicit 
func (d) ; //  Automatic  type  conversion 

func (static_cast<int> (d) ) ; //  More  explicit 
} ///:- 

In  Section  (1),  you  see  the  kinds  of  conversions  you're  used  to 
doing  in  C,  with  or  without  a cast.  Promoting  from  an  intto  a long 
orfloatisnot  a problem  because  the  latter  can  always  hold  every 
valuethatan  intcan  contain.  Although  it's  unnecessary,  you  can 
usestatic_castto  highlight  these  promotions. 

Converting  back  the  other  way  isshown  in  (2).  Here,  you  can  lose 
data  because  an  intis  not  as  "wide"  as  a longer  afloat  it  won't 
hold  numbersof  the  same  size.  Thus  these  are  cal  led  narrowing 
coni/ers/'ons.  The  compiler  will  still  perform  these,  but  will  often  give 
you  a warning.  You  can  eliminate  this  warning  and  indicate  that 
you  really  did  mean  it  using  a cast. 

Assigning  from  a void*  is  not  all  owed  without  a cast  in  C++ (uni  ike 
C),  as  seen  in  (3).  This  is  dangerous  and  requires  that  programmers 
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know  what  they're  doing.  Thestatic_castat  least,  iseasier  to  locate 
than  the  old  standard  cast  when  you're  hunting  for  bugs. 

Section  (4)  of  the  program  shows  the  kinds  of  implicit  type 
conversionsthat  are  normally  performed  automatically  by  the 
compiler.  These  are  automatic  and  require  no  casting,  but  again 
static_casthighlights  the  action  in  case  you  want  to  makeit  clear 
what's  happening  or  huntfor  it  later. 

const_cast 

If  you  want  to  convert  from  a constto  a nonconstor  from  a volatile 
to  a nonvolatile  you  useconst_castThis  i s the  on/y  conversion 
allowed  with  const_castif  any  other  conversion  isinvolved  it  must 
be  done  usi  ng  a separate  express! on  or  you'l  I get  a compi  le-ti  me 
error. 


//:  COS : const_cast . cpp 
int  main  ( ) { 

const  int  i = 0; 

int*  j = (int*)&i;  //  Deprecated  form 
j = const_cast<int*> (&i) ; //  Preferred 
//  Can't  do  simultaneous  additional  casting: 

//!  long*  1 = const_cast<long*> (&i) ; //  Error 

volatile  int  k = 0; 
int*  u = const_cast<int*> (&k) ; 

} ///:- 

If  you  take  the  address  of  a constobject,  you  produce  a pointer  to  a 
const  and  this  cannot  be  assigned  to  a nonconstpointer  without  a 
cast.  The  old-style  cast  will  accomplish  this,  but  the  const_  casts 
the  appropri  ate  one  to  use.  The  same  hoi  ds  true  for  vol  ati  le 

reinterpret_  cast 

Thi  s i s the  I east  safe  of  the  casti  ng  mechani  sms,  and  the  one  most 
likely  to  produce  bugs.  A reinterpret_cas^Dretendsthat  an  object  is 
just  a bit  pattern  that  can  be  treated  (for  some  dark  purpose)  as  if  it 
were  an  entirely  different  type  of  object.  This  is  the  low-level  bit 
twiddling  that  C is  notorious  for.  You'll  virtually  always  need  to 
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reinterpret_cast)ack  to  the  original  type  (or  otherwise  treat  the 
variable  as  its  original  type)  before  doing  anything  else  with  it. 

//:  COS : reinterpret_cast . cpp 
#include  <iostream> 
using  namespace  std; 
const  int  sz  = 100; 

struct  X { int  a[sz];  }; 

void  print (X*  x)  { 

for(int  i = 0;  i < sz;  i++) 
cout  <<  x->a[i]  <<  ' '; 

cout  <<  endl  <<  " " <<  endl; 

} 

int  main  ( ) { 

X X ; 

print (&x) ; 

int*  xp  = reinterpret_cast<int*>  (&x)  ; 
for  (int*  i = xp;  i < xp  + sz;  i++) 

*i  = 0; 

//  Can't  use  xp  as  an  X*  at  this  point 
//  unless  you  cast  it  back: 
print (reinterpret_cast<X*> (xp) ) ; 

//  In  this  example,  you  can  also  just  use 
//  the  original  identifier: 
print (&x) ; 

} ///:- 

I n thi  s si  mpl  e exampl  e,  struct  Xjust  contai  ns  an  array  of  i nt;  but 
when  you  create  one  on  the  stack  as  in  X x,  the  values  of  each  of  the 
ints  are  garbage  (this  isshown  using  theprint(  )function  to  display 
the  contents  of  the  struck.  To  i nitial  ize  them,  the  add ress  of  the X is 
taken  and  cast  to  an  int  pointer,  which  isthen  walked  through  the 
array  to  set  each  intto  zero.  N otice  how  the  upper  bound  for  i is 
calculated  by  "adding"  sz  to  xp;  the  compiler  knowsthatyou 
actually  want  sz  pointer  locations  greater  than  xp  and  it  does  the 
correct  pointer  arithmetic  for  you. 

The  idea  of  reinterpret_ casts  that  when  you  use  it,  what  you  get  is 
so  foreign  that  it  cannot  be  used  for  the  type's  original  purpose 
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unless  you  cast  it  back.  Here,  wesee  the  cast  back  to  an  X*  in  the 
call  to  print,  but  of  course  si  nee  you  still  have  the  original  identifier 
you  can  also  use  that.  Butthexp  is  only  useful  as  an  int*,  which  is 
truly  a "reinterpretation"  of  the  original  X. 

A reinterpret_cast)ften  indicates  inadvisable  and/  or  nonportable 
programming,  but  it's  avail  able  when  you  decide  you  have  to  use 
it. 


sizeof  - an  operator  by  itself 

The  si zeof  operator  stands  alone  because  it  satisfies  an  unusual 
need,  si  zeof  gives  you  information  about  the  amount  of  memory 
allocated  for  data  items.  Asdescribed  earlier  in  thischapter,  sizeof 
tel  Is  you  the  number  of  bytes  used  by  any  particular  variable.  It  can 
also  give  the  size  of  a data  type  (with  no  variable  name): 

//:  COS : sizeof . epp 
#include  <iostream> 
using  namespace  std; 
int  main  ( ) { 

cout  <<  "sizeof (double)  = " <<  sizeof (double) ; 
cout  <<  ",  sizeof (char)  = " <<  sizeof (char)  ; 

} ///:- 

By  definition,  thesizeofany  typeof  char(signeci  unsignedor 
plain)  is  always  one,  regardlessof  whether  the  underlying  storage 
for  a char  is  actually  one  byte.  For  all  other  types,  the  result  is  the 
size  in  bytes. 

Notethatsizeofisan  operator,  not  a function.  If  you  apply  it  to  a 
type,  it  must  be  used  with  the  parenthesized  form  shown  above, 
but  if  you  apply  it  to  a variable  you  can  use  it  without  parentheses: 

//:  COS : sizeofOperator . epp 
int  main  ( ) { 

int  X ; 

int  i = sizeof  x; 

} ///:- 
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sizeof  can  also  give  you  the  sizes  of  user-defined  data  types.  This  is 
used  later  in  the  book. 


The  asm  keyword 

This  is  an  escape  mechanism  that  allows  you  to  write  assembly 
codefor  your  hardware  within  a C-H- program.  Often  you're  able 
to  reference  C-H- variables  with  in  the  assembly  code,  which  means 
you  can  easily  communicate  with  your  C-H- code  and  limitthe 
assembly  code  to  that  necessary  for  efficiency  tuning  or  to  use 
special  processor  instructions.  The  exact  syntax  that  you  must  use 
when  writing  the  assembly  language  is  compiler-dependent  and 
can  bediscovered  in  your  compiler'sdocumentation. 

Explicit  operators 

These  are  keywords  for  bitwise  and  logical  operators.  Non-U  .S. 
programmers  without  keyboard  characters  I i ke  & , | , and  so  on, 
wereforced  to  useC's  horrible  trigraphs,  which  were  not  only 
annoying  to  type,  but  obscure  when  reading.  This  is  repaired  in 
C-H-with  additional  keywords: 


Keyword 

Meaning 

and 

&&  (logical  and) 

or 

1 1 (logical  or) 

not 

! (logical  NOT) 

not_eq 

!=  (logical  not-equi valent) 

bitand 

& (bitwise and) 

and_eq 

& = (bitwise  an  d-assignment) 

bitor 

1 (bitwise  or) 

or_eq 

1 = (bitwise  or-assignment) 

xor 

(bitwiseexclusive-or) 

3:  The  C in  C-I--I- 


187 


Keyword 

Meaning 

xor_eq 

''^=(bitwiseexdusive-or- 

assignment) 

compi 

~ (ones  complement) 

If  your  compiler  complies  with  Standard  C++,  it  will  support  these 
keywords. 


Composite  type  creation 

The  fundamental  data  types  and  their  variations  are  essential,  but 
rather  primitive.  C and  C++ providetools that  allow  you  to 
compose  more  sophisticated  data  types  from  thefundamental  data 
types.  As  you 'I  I see,  the  most  important  of  these  is  struct  which  is 
the  foundation  for  cl  ass  in  C++.  However,  thesimplest  way  to 
create  more  sophisticated  types  is  simply  to  alias  a name  to  another 
name  via  typed ef. 

Aliasing  names  with  typedef 

This  keyword  promises  more  than  it  delivers:  typedef  suggests 
"type definition"  when  "alias"  would  probably  have  been  a more 
accurate  description,  si  nee  that's  what  it  really  does.  The  syntax  is: 

typedef  exi sting-type-description  alias-name 

People  often  use  typedef  when  datatypes  get  slightly  complicated, 
just  to  prevent  extra  keystrokes.  H ere  is  a commonly-used  typedef 

I typedef  unsigned  long  ulong; 

Now  if  you  say  ulongthe  compiler  knows  that  you  mean  unsigned 
long  You  might  think  that  this  could  as  easily  be  accompli  shed 
using  preprocessor  substitution,  but  there  are  key  situations  in 
which  the  compiler  must  be  aware  that  you 're  treating  a name  as  if 
it  were  a type,  so  typedef  i s essenti al . 


188 


Thinking  in  C+  + 


www.BruceEckel.com 


One  pi  ace  where  typedef  comes  in  handy  is  for  pointer  types.  As 
previously  mentioned,  if  you  say: 


I int*  X,  y; 

This  actually  produces  an  int*  which  is x and  an  int(notan  int*) 
which  isy.  That  is,  the'*'  binds  to  the  right,  nottheleft.  However, 
if  you  use  a typedef 

typedef  int*  IntPtr; 

IntPtr  X,  y; 

Then  both  x and  y are  of  type  i nt*. 

You  can  argue  that  it's  more  explicit  and  therefore  more  readable  to 
avoid  typedefe  for  primitive  types,  and  indeed  programs  rapidly 
become  difficult  to  read  when  many  typedefe  are  used.  However, 
typedef  become  especially  important  in  C when  used  with  struct 

Combining  variabies  with  struct 

A struct! s a way  to  col  lect  a group  of  variables  into  a structure. 
Once  you  create  a struct  then  you  can  make  many  instances  of  this 
"new"  typeof  variable  you 'vein  vented.  For  example: 

//:  COS : SimpleStruct . cpp 
struct  Structurel  { 
char  c; 
int  i ; 
float  f; 
double  d; 

}; 

int  main  ( ) { 

struct  Structurel  si,  s2; 

sl.c  = 'a';  //  Select  an  element  using  a 

si . 1 = 1 ; 

sl.f  = 3.14; 

sl.d  = 0.00093; 

s2 . c = ' a ' ; 

s2 . 1 = 1 ; 

s2.f  = 3.14; 
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s2.d  = 0.00093; 

} III-.- 

Thestructdeclaration  must  end  with  a semicolon.  In  main(  )two 
i nstances  of  Structurelare  created : si  and  s2.  Each  of  these  has 
theirown  separate  versions  of  c,  i,f,  and  d.  So  si  and  s2  represent 
cl  u mps  of  compi  etel  y i nd epend ent  vari  abl  es.  To  sel  ect  one  of  the 
elements  within  si  or  s2,  you  use  a syntax  you've  seen  in  the 
previous  chapter  when  using  C++classobjects-  sinceclas^ 
evolved  from  struck,  this  is  where  that  syntax  arose  from. 

One  thing  you'll  noticeistheawkwardnessof  the  use  of  Structure! 
(as  it  turns  out,  this  isonly  required  by  C,  notC++).  In  C,  you  can't 
just  say  Structurelwhen  you're  defining  variables,  you  must  say 
struct  StructurelThis  is  where typedef  becomes  especially  handy 
in  C: 


//:  COS : SimpleStruct2 . cpp 
//  Using  typedef  with  struct 
typedef  struct  { 
char  c; 
int  i ; 
float  f; 
double  d; 

} Structure2; 

int  main  ( ) { 

Structure2  si,  s2; 
si . c = ' a ' ; 
si . i = 1 ; 
sl.f  = 3.14; 
sl.d  = 0.00093; 
s2 . c = ' a ' ; 
s2 . i = 1 ; 
s2.f  = 3.14; 
s2.d  = 0.00093; 

} ///:- 

By  using  typedef  in  this  way,  you  can  pretend  (in  C;try  removing 
the  typedrffor  C ++)  that  Structu re2i  s a bu i It-i  n type,  I i ke  i nt or 
float  when  you  define  si  and  s2(but  notice  it  only  has  data - 
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characteristics  - and  does  not  inciude  behavior,  which  is  what  we 
getwith  reai  objectsin  C++).  You'ii  noticethat  the  struct!  dentifier 
has  been  ieft  off  at  the  beginning,  because  the  goai  is  to  create  the 
typedef.  However,  there  are  times  when  you  might  need  to  refer  to 
the structdu ring  its  definition,  in  those  cases,  you  can  actuaiiy 
repeat  the  name  of  the  structas  the  structname  and  as  the  typedef 

// : COS : SelfReferential . cpp 
//  Allowing  a struct  to  refer  to  itself 

typedef  struct  SelfReferential  { 
int  1 ; 

SelfReferential*  sr;  //  Head  spinning  yet? 

} SelfReferential; 

int  main  ( ) { 

SelfReferential  srl,  sr2; 

srl . sr  = &sr2 ; 

sr2 . sr  = &srl ; 

srl .1  = 47 ; 

sr2 .1  = 1024 ; 

} ///:- 

if  you  iookatthisforawhiie,  you'ii  see  that  srl  and  sr2  point  to 
each  other,  asweii  as  each  hoiding  a piece  of  data. 

Actuaiiy,  the  structname  does  not  have  to  be  the  same  as  the 
typedefname,  but  it  isusuaiiy  donethisway  as  it  tends  to  keep 
things  simpier. 

Pointers  and  structs 

in  the  exampies  above,  aii  the  struct  are  manipuiated  as  objects. 

H owever,  i i ke  any  pi  ece  of  storage,  you  can  take  the  add  ress  of  a 
structobject  (as seen  in  SelfReferential .cppabove).  To  seiect the 
eiements  of  a parti cuiar  structobject,  you  usea as  seen  above. 
However,  if  you  have  a pointer  to  a structobject,  you  must  seiect 
an  dement  of  that  object  using  a different  operator:  the'->'.  Here's 
an  exampie: 

//:  COS : SimpleStructS . cpp 
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//  Using  pointers  to  structs 
typedef  struct  Structures  { 
char  c; 
int  i ; 
float  f; 
double  d; 

} structures; 

int  main  ( ) { 

structures  si,  s2; 
structures*  sp  = &sl; 
sp->c  = ' a ' ; 
sp->i  = 1; 
sp->f  = S.14; 
sp->d  = 0.0009S; 

sp  = &s2;  //  Point  to  a different  struct  object 

sp->c  = ' a ' ; 

sp->i  = 1; 

sp->f  = S.14; 

sp->d  = 0.0009S; 

} ///:- 

In  main( ) thestructpointer  sp  is  initially  pointing  to  si,  and  the 
mennbers  of  si  are  initialized  by  selecting  thenn  with  the'->'  (and 
you  usethis  same  operator  in  order  to  read  those  members).  But 
then  sp  is  pointed  to  s2,  and  those  variables  are  initialized  the  same 
way.  So  you  can  see  that  another  benefit  of  pointers  is  that  they  can 
be  dynamically  redirected  to  point  to  different  objects;  this 
provides  more  flexibility  in  your  programming,  as  you  will  learn. 

For  now,  that's  all  you  need  to  know  about  struck,  but  you'll 
become  much  more  comfortable  with  them  (and  especially  their 
more  potent  successors,  clas^)  as  the  book  progresses. 

Clarifying  programs  with  enum 

An  enumerated  datatypeisaway  of  attaching  names  to  numbers, 
thereby  giving  more  meaning  to  anyone  reading  the  code.  The 
enum  keyword  (from  C)  automatically  enumerates  any  list  of 
identifiers  you  give  it  by  assigning  them  values  of  0, 1,  2,  etc.  You 
can  declare  enum  variables  (which  are  always  represented  as 
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integral  values).  The  declaration  of  an  enum  looks  similar  to  a 
structdeclaration. 

An  enumerated  data  type  is  useful  when  you  want  to  keep  track  of 
some  sort  of  f eatu  re: 

//:  COS :Enum. cpp 
//  Keeping  track  of  shapes 

enum  ShapeType  { 
circle, 
square, 
rectangle 

};  //  Must  end  with  a semicolon  like  a struct 

int  main  ( ) { 

ShapeType  shape  = circle; 

//  Activities  here. . . . 

//  Now  do  something  based  on  what  the  shape  is: 
switch ( shape ) { 

case  circle:  /*  circle  stuff  */  break; 
case  square:  /*  square  stuff  */  break; 
case  rectangle:  /*  rectangle  stuff  */  break; 

} 

} ///:- 

shapeisa  variableof  theShapeTypeenumerated  datatype,  and  its 
value  is  compared  with  thevaluein  theenumeration.  Si  nee  shape 
is  really  just  an  int  however,  it  can  beany  value  an  int  can  hold 
(including  a negative  number).  You  can  also  compare  an  int 
vari abl e w ith  a val ue  i n the  enu merati on. 

You  should  be  aware  that  the  example  above  of  switching  on  type 
turns  out  to  be  a problematic  way  to  program.  C++ has  a much 
better  way  to  code  this  sort  of  thing,  the  explanation  of  which  must 
be  delayed  until  much  later  in  the  book. 

If  you  don't  I ike  the  way  the  compiler  assigns  values,  you  can  do  it 
yourself,  I ike  this: 

enum  ShapeType  { 
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circle 


50 


= 10,  square  = 20,  rectangle  = 

}; 

If  you  givevaluesto  some  names  and  not  to  others,  the  compiler 
will  usethe  next  integral  value.  For  example, 

enum  snap  { crackle  = 25,  pop  } ; 

The  compi  ler  gives  pop  the  value  26. 

You  can  see  how  much  morereadablethecodeiswhen  you  use 
enumerated  datatypes.  However,  to  some  degree  this  is  still  an 
attempt  (in  C)  to  accomplish  the  things  that  we  can  do  with  a class 
in  C++,  so  you'll  see  enum  used  less  in  C++. 

Type  checking  for  enumerations 

C's  enumerations  are  fairly  primitive,  simply  associating  integral 
values  with  names,  but  they  provide  no  type  checking.  In  C++,  as 
you  may  have  come  to  expect  by  now,  the  concept  of  type  is 
fundamental,  and  this  istruewith  enumerations.  When  you  create 
a named  enumeration,  you  effectively  create  a new  type  just  as  you 
do  with  a class:  Thenameof  your  enumeration  becomes  a reserved 
word  for  the  duration  of  that  translation  unit. 

I n add i ti on,  there's  stri cter  type  checki ng  for  enu merati ons  i n C ++ 
than  in  C.  You'll  notice  this  in  particular  if  you  havean  instance  of 
an  enumeration  col  or  cal  led  a.  In  C you  can  say  a++,butin  C++ 
you  can't.  This  is  because  incrementing  an  enumeration  is 
performing  two  type  conversions,  one  of  them  legal  in  C++ and  one 
of  them  illegal.  First,  the  value  of  the  enu  merati  on  is  implicitly  cast 
from  a col  or  to  an  int;  then  thevalue  is  incremented,  then  the  intis 
cast  back  into  a color.  In  C++ this  isn't  allowed,  because  color  is  a 
distinct  type  and  not  equivalent  to  an  int  This  makes  sense, 
because  how  do  you  know  the  increment  of  bluewill  even  beinthe 
list  of  colors?  If  you  want  to  increment  a color,  then  it  should  be  a 
class  (with  an  increment  operation)  and  not  an  enum,  because  the 
class  can  be  madeto  be  much  safer.  Any  time  you  write  codethat 
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assu mes  an  i mpl  i cit  conversi  on  to  an  enum  type,  the  compi  I er  w i 1 1 
flag  this  inherently  dangerous  activity. 

Unions  (described  next)  have  similar  additional  type  checking  in 
C++. 

Saving  memory  with  union 

Someti  mes  a program  will  hand  I e d ifferent  types  of  data  usi  ng  the 
same  variable.  In  this  situation,  you  havetwo  choices:  you  can 
create  a structcontaining  all  the  possible  different  types  you  might 
need  to  store,  or  you  can  usea  union.  A unionpilesall  the  data 
into  a si  ngle  space;  it  figures  out  the  amount  of  space  necessary  for 
thelargest  item  you've  put  in  theunion,  and  makes  that  the  size  of 
the  union.  Usea  union  to  save  memory. 

Anytime  you  place  a value  in  a union,  the  value  always  starts  in 
the  same  pi  ace  at  the  beginning  of  theunion,  but  only  uses  as  much 
space  as  is  necessary.  Thus,  you  createa  "super-variable"  capable 
of  holding  any  of  the  union  variables.  A 1 1 the  addresses  of  the 
u n i on  vari  abl  es  are  the  same  ( i n a cl  ass  or  struct  the  ad  d resses  are 
different). 

H ere's  a simple  use  of  a union.  Try  removi  ng  various  elements  and 
seewhat  effect  it  has  on  the  size  of  theunion.  Notice  that  it  makes 
no  sense  to  declare  more  than  one  instance  of  a si  ngle  data  type  in  a 
union  (unless  you're  just  doing  it  to  use  a different  name). 

//:  COS : Union . cpp 

//  The  size  and  simple  use  of  a union 
#include  <iostream> 
using  namespace  std; 

union  Packed  { //  Declaration  similar  to  a class 
char  i; 
short  j; 
int  k ; 
long  1; 
float  f; 
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double  d; 

//  The  union  will  be  the  size  of  a 
//  double,  since  that's  the  largest  element 
};  //  Semicolon  ends  a union,  like  a struct 

int  main  ( ) { 

cout  <<  "sizeof (Packed)  = " 

<<  sizeof (Packed)  <<  endl; 

Packed  x; 

X . i = ' c ' ; 

cout  <<  x.i  <<  endl; 
x.d  = 3.14159; 
cout  <<  x.d  <<  endl; 

} ///:- 

The  compiler  performs  the  proper  assignment  according  to  the 
union  member  you  select. 

Once  you  perform  an  assignment,  the  compiler  doesn't  care  what 
you  do  with  the  union.  In  the  example  above,  you  could  assign  a 
fl  oati  ng-poi  nt  val  ue  to  x: 

I x.f  = 2.222; 

and  then  send  it  to  the  output  as  if  it  were  an  int 

I cout  <<  x.i; 

This  would  produce  garbage. 

Arrays 

A rrays  are  a ki  nd  of  composite  type  because  they  al  I ow  you  to 
clump  a lot  of  variables  together,  one  right  after  the  other,  under  a 
single  identifier  name.  If  you  say: 

I int  a [ 10 ] ; 

You  create  storage  for  10  int  variables  stacked  on  top  of  each  other, 
but  without  unique  identifier  names  for  each  variable.  Instead,  they 
are  all  lumped  under  the  name  a. 
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To  access  one  of  these  array  dements,  you  use  the  same  square- 
bracket  syntax  that  you  use  to  defi  ne  an  array: 

a[5]  = 47; 

H owever,  you  must  remember  that  even  though  the  size  of  a i s 10, 
you  select  array  elements  start!  ng  at  zero  (this  is  someti  mes  cal  led 
zero  indexing),  so  you  can  select  only  the  array  elements  0-9,  like 
this: 

//:  COS : Arrays . cpp 
#include  <iostream> 
using  namespace  std; 

int  main  ( ) { 

int  a [ 10 ] ; 

for(int  i = 0;  i < 10;  i++)  { 

a[i]  = i * 10; 

cout  <<  "a["  <<  1 <<  "]  = " <<  a[i]  <<  endl; 

} 

} ///:- 

Array  access  is  extremely  fast.  H owever,  if  you  I ndex  past  the  end 
of  the  array,  there  is  no  safety  net  - you'll  step  on  other  variables. 
The  other  drawback  is  that  you  must  define  the  size  of  the  array  at 
compile  time;  if  you  want  to  change  the  size  at  runtime  you  can't 
do  it  with  the  syntax  above  (C  does  have  a way  to  create  an  array 
dynamically,  but  it's  significantly  messier).  The C-H- vector, 
introduced  in  the  previous  chapter,  provides  an  array-1  ike  object 
that  automatically  resizes  itself,  so  it  is  usually  a much  better 
solution  if  your  array  size  cannot  be  known  at  compile  time. 

You  can  make  an  array  of  any  type,  even  of  struck: 

//:  COS : StructArray . cpp 
//  An  array  of  struct 

typedef  struct  { 

Int  1,  j,  k; 

} ThreeDpolnt; 
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int  main  ( ) { 

ThreeDpoint  p[10]; 
for(int  i = 0;  i < 10;  i++)  { 

p [i]  . i = i + 1; 
p [i]  . j = i + 2; 
p [i]  .k  = i + 3; 


} ///:- 

N oti  ce  how  the  struct!  dentifi  er  i i s i ndependent  of  the  for  I oop's  i . 

To  see  that  each  element  of  an  array  is  contiguous  with  the  next, 
you  can  print  out  the  addresses  I ike  this: 

//:  COS : ArrayAddresses . cpp 
#include  <iostream> 
using  namespace  std; 


int  main  ( ) { 

int  a [ 10 ] ; 

cout  <<  "sizeof(int)  = "<<  sizeof(int)  <<  endl; 
for(int  i = 0;  i < 10;  i++) 
cout  <<  "&a["  <<!<<"]=  " 

<<  (long)&a[i]  <<  endl; 

} ///:- 

When  you  run  thisprogram,  you'll  see  that  each  element  isoneint 
size  away  from  the  previous  one.  That  is,  they  are  stacked  one  on 
top  of  the  other. 

Pointers  and  arrays 

The  identifier  of  an  array  is  unlikethe  identifiersfor  ordinary 
variables.  For  one  thing,  an  array  identifier  is  not  an  lvalue;  you 
cannot  assign  to  it.  It's  really  just  a hook  into  the  square-bracket 
syntax,  and  when  you  givethenameof  an  array,  without  square 
brackets,  what  you  get  is  the  starting  address  of  the  array: 

//:  COS : Arrayidentif ier . cpp 
#include  <iostream> 
using  namespace  std; 

int  main  ( ) { 


198 


Thinking  in  C-I--I- 


www.BruceEckel.com 


int  a [ 10 ] ; 

cout  <<  "a  = " <<  a <<  endl; 

cout  <<  "&a[0]  ="  <<  &a[0]  <<  endl; 

} ///:- 

When  you  run  this  program  you'll  see  that  thetwo  addresses 
(which  will  be  printed  in  hexadecimal,  si  nee  there  is  no  cast  to 
long)  are  the  same. 

So  oneway  to  look  at  the  array  identifier  is  as  a read-only  pointer 
to  the  beginning  of  an  array.  And  although  we  can't  change  the 
array  identifier  to  point  somewhere  else,  we  can  create  another 
poi  nter  and  use  that  to  move  arou  nd  i n the  array.  I n fact,  the 
square-bracket  syntax  works  with  regular  pointers  as  well: 

//:  COS : PointersAndBrackets . epp 
int  main  ( ) { 

int  a [ 10 ] ; 
int*  ip  = a; 

for(int  i = 0;  i < 10;  i++) 
ip[i]  = i * 10; 

} ///:- 

The  fact  that  naming  an  array  produces  its  starting  address  turns 
out  to  be  quite  i mportant  when  you  want  to  pass  an  array  to  a 
function.  If  you  declare  an  array  as  a function  argument,  what 
you're  really  declaring  is  a pointer.  So  in  the  following  example, 
funcl(  )and  func2(  )effectively  have  the  same  argument  lists: 

//:  COS : ArrayArguments . epp 
#include  <iostream> 

#include  <string> 
using  namespace  std; 

void  fund  (int  a[],  int  size)  { 
for(int  i = 0;  i < size;  i++) 
a[i]  =i*i-i; 

} 


void  func2(int*  a,  int  size)  { 
for(int  i = 0;  i < size;  i++) 
a[i]  =i*i+i; 
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} 


void  print  (int  a[],  string  name,  int  size)  { 
for(int  i = 0;  i < size;  i++) 

cout  <<  name  <<  "["  <<  i <<  "]  = " 

<<  a[i]  <<  endl; 

} 


rnt  main  ( ) { 

int  a [ 5 ] , b [ 5 ] ; 

//  Probably  garbage  values: 


print (a,  "a" , 

print (b,  "b" , 

/ / Initialize 
fund  (a,  5)  ; 
fund  (b,  5)  ; 
print  (a,  "a" , 

print (b,  "b" , 

//  Notice  the 
func2 (a,  5) ; 
func2 (b,  5) ; 
print (a,  "a" , 

print  (b,  "b" , 

} ///:- 


5)  ; 

5)  ; 

the  arrays : 


5)  ; 

5)  ; 

arrays  are  always 


5)  ; 
5)  ; 


modified: 


Even  though  funcl(  )and  func2(  )decl  are  their  arguments 
differently,  the  usage  is  the  same  inside  the  function.  There  are 
some  other  issues  that  this  example  reveals:  arrays  cannot  be 
passed  by  valued,  that  is,  you  never  automatically  get  a local  copy 
of  the  array  that  you  pass  into  a function.  Thus,  when  you  modify 
an  array,  you're  always  modifying  theoutsideobject.  This  can  be  a 
bit  confusing  at  first,  if  you're  expecting  the  pass-by-value 
provided  with  ordinary  arguments. 


^Unless  you  take  the  very  strict  approach  that  "all  argument  passing  in  C/  C-H-is  by 
value,  and  the  'value'  of  an  array  is  what  is  produced  by  the  array  identifier:  it's 
address."  Thiscan  be  seen  as  true  from  the  assembly-language  standpoint,  buti  don't 
think  it  helps  when  trying  to  work  with  higher-level  concepts.  The  addition  of 
references  in  C-H- makes  the  "all  passing  is  by  value"  argument  more  confusing,  to 
the  point  where  I feel  it's  more  helpful  to  think  in  terms  of  "passing  by  value"  vs. 
"passing  addresses." 
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You'll  not! ce that  print(  )uses  the  square-bracket  syntax  for  array 
arguments.  Even  though  the  pointer  syntax  and  the  square-bracket 
syntax  are  effectively  the  same  when  pass!  ng  arrays  as  arguments, 
the  square-bracket  syntax  makes  it  clearer  to  the  reader  that  you 
mean  for  this  argument  to  bean  array. 

Also  note  that  thesizeargument  is  passed  in  each  case.  Just  passing 
the  address  of  an  array  isn't  enough  information;  you  must  always 
beableto  know  how  big  the  array  is  insideyour  function,  so  you 
don't  run  off  the  end  of  that  array. 

A rrays  can  be  of  any  type,  i ncl  ud  i ng  arrays  of  poi  nters.  I n fact, 
when  you  want  to  pass  command-line  arguments  into  your 
program,  C and  C-H- have  a special  argument  list  for  main( ) 
which  looks  I ike  this: 

int  main(int  argc,  char*  argv [ ] ) { //  ... 

The  first  argument  is  the  number  of  elements  in  the  array,  which  is 
the  second  argument.  The  second  argument  is  always  an  array  of 
char*,  because  the  arguments  are  passed  from  the  command  I ine  as 
character  arrays  (and  remember,  an  array  can  be  passed  only  as  a 
pointer).  Each  whitespace-delimited  cluster  of  characters  on  the 
command  I i ne  i s tu  rned  i nto  a separate  array  argu  ment.  The 
following  program  prints  out  all  its  command-1  ine  arguments  by 
steppi  ng  through  the  array: 

//:  COS : CommandLineArgs . cpp 
#include  <iostream> 
using  namespace  std; 

int  main (int  argc,  char*  argv [ ] ) { 

cout  <<  "argc  = " <<  argc  <<  endl; 
for  (int  i = 0;  i < argc;  i++) 
cout  <<  "argv["  <<  i <<  "]  = " 

<<  argv[i]  <<  endl; 

} ///:- 
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You'll  noticethatargv[0]is  the  path  and  name  of  the  program 
itself.  This  allowsthe  program  to  discover  information  about  itself. 
It  also  adds  one  more  to  the  array  of  program  arguments,  so  a 
common  error  when  fetchi ng  command-1  i ne  arguments  i s to  grab 

argv[0]when  you  want  argv[l] 

You  are  not  forced  to  useargcand  argvas  identifiers  in  main( ) 
those  identifiers  are  only  conventions  (but  it  will  confuse  people  if 
you  don't  use  them).  Also,  there  is  an  alternateway  to  declare  argv: 

int  main(int  argc,  char**  argv)  { //  ... 

Both  forms  are  equivalent,  but  I find  the  version  used  in  this  book 
to  be  the  most  intuitive  when  reading  the  code,  si  nee  it  says, 
directly,  "This  is  an  array  of  character  pointers." 

All  you  get  from  the  command-line  is  character  arrays;  if  you  want 
to  treat  an  argument  as  some  other  type,  you  are  responsi  ble  for 
converti  ng  it  i nsi de  your  program.  T o faci  I itate  the  conversion  to 
numbers,  there  are  some  helper  functions  in  the  Standard  C library, 
declared  in  <cstdlib>  The  simplest  ones  to  useareatoi( ) atol( ), 
and  atof(  )to  convert  an  ASCI  I character  array  to  an  int;  long, and 
doublefloating-point  value,  respectively.  Here'san  exampleusing 
atoi(  )(the  other  two  functions  are  cal  led  the  same  way): 

//:  COS : ArgsToInts . epp 

//  Converting  command-line  arguments  to  ints 
#include  <iostream> 

#include  <cstdlib> 
using  namespace  std; 

int  main (int  argc,  char*  argv [ ] ) { 

for  (int  i = 1;  i < argc;  it+) 
cout  <<  atoi  (argv [i] ) <<  endl; 

} ///:- 

In  this  program,  you  can  put  any  number  of  arguments  on  the 
command  line.  You'll  noti  ce  that  the  for  loop  starts  at  the  value  1 to 
ski  p over  the  program  name  at  argv[0]  A I so,  if  you  putafloating- 
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point  number  containing  a decimal  point  on  the  command  line, 
atoi(  )takes  only  the  digits  up  to  the  decimal  point.  If  you  put  non- 
numbers on  the  command  line,  these  come  back  from  atoi(  )as 
zero. 

Exploring  floating-point  format 
The  printBi nary ( function  introduced  earlier  in  this  chapter  is 
handy  for  delving  into  the  internal  structure  of  various  data  types. 
The  most  interesting  of  these  is  the  floating-point  format  that 
allows  C and  C-H-to  store  numbers  representing  very  large  and 
very  small  values  in  a limited  amountof  space.  Although  the 
details  can't  be  completely  exposed  here,  thebits  inside  of  float 
and  doubles  are  divided  into  three  regions:  the  exponent,  the 
mantissa,  and  the  sign  bit;  thus  it  stores  the  values  using  scientific 
notation.  The  foil  owing  program  allows  you  to  play  around  by 
printing  out  the  binary  patterns  of  various  floating  point  numbers 
so  you  can  deducefor  yourself  the  scheme  used  in  your  compiler's 
fl oati  ng-poi nt  format  (usual  ly  thi s i s the  IEEE  standard  for  fl oati  ng 
point  numbers,  but  your  compiler  may  not  follow  that): 

//:  COS : FloatingAsBinary . cpp 
//{L}  printBinary 
//{T}  3.14159 
#include  "printBinary . h" 

#include  <cstdlib> 

#include  <iostream> 
using  namespace  std; 

int  main(int  argc,  char*  argv [ ] ) { 

if  (argc  ! = 2 ) { 

cout  <<  "Must  provide  a number"  <<  endl; 
exit ( 1 ) ; 

} 

double  d = atof (argv [ 1 ] ) ; 
unsigned  char*  cp  = 

reinterpret_cast<unsigned  char*> (&d) ; 
for (int  i = sizeof (double) ; i > 0 ; i -=  2)  { 

printBinary (cp [ i-1 ] ) ; 
printBinary (cp [i] ) ; 

} 
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} III-.- 


Fi  rst,  the  program  guarantees  that  you've  given  it  an  argument  by 
checking  the  value  of  argc  which  istwo  if  there's  a single  argument 
(it's  one  if  there  are  no  arguments,  si  nee  the  program  name  is 
al  ways  the  first  element  of  argv).  Ifthisfails,  a message  is  printed 
and  the  Standard  C Library  function  exit(  )iscalled  to  terminate 
the  program. 

The  program  grabs  the  argument  from  the  command  line  and 
converts  the  characters  to  a doubleusing  atof(  )Then  thedoubleis 
treated  as  an  array  of  bytes  by  taking  the  address  and  casting  it  to 
an  unsigned  char*Each  of  these  bytes  is  passed  to  printB inary ( ) 
for  display. 

This  example  has  been  set  up  to  print  the  bytes  in  an  order  such 
that  the  sign  bit  appears  first-  on  my  machine.  Yours  may  be 
different,  so  you  might  want  to  re-arrange  the  way  things  are 
printed.  You  should  also  be  aware  that  floating-point  formats  are 
not  trivial  to  understand;  for  example,  the  exponent  and  mantissa 
are  not  generally  arranged  on  byte  boundaries,  but  instead  a 
number  of  bits  is  reserved  for  each  one  and  they  are  packed  i nto  the 
memory  as  tightly  as  possible.  To  truly  see  what's  going  on,  you'd 
need  to  find  out  the  size  of  each  part  of  the  number  (sign  bits  are 
always  one  bit,  but  exponents  and  mantissas  are  of  differing  sizes) 
and  print  out  the  bits  in  each  part  separately. 

Pointer  arithmetic 

If  all  you  could  do  with  a pointer  that  points  at  an  array  istreat  it  as 
if  it  were  an  al  i as  for  that  array,  poi  nters  i nto  arrays  wou  I d n't  be 
very  interesting.  However,  pointers  are  more  flexible  than  this, 
since  they  can  be  modified  to  point  somewhere  else  (but  remember, 
the  array  identifier  cannot  be  modified  to  point  somewhere  else). 

Pointer  arithmetic  refers  to  the  appi  ication  of  some  of  the  arithmetic 
operators  to  pointers.  The  reason  pointer  arithmetic  is  a separate 
subject  from  ordinary  arithmetic  is  that  pointers  must  conform  to 
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special  constraints  in  order  to  makethenn  behave  properly.  For 
example,  a common  operator  to  use  with  pointers  is  ++,  which 
"adds  oneto  the  pointer."  What  this  actually  means  isthatthe 
pointer  is  changed  to  move  to  "the  next  value,"  whatever  that 
means.  Here's  an  example: 


//:  COS : Pointerlncrement . cpp 
#include  <iostream> 
using  namespace  std; 


int  main  ( ) { 

int  i [ 10 ] ; 
double  d [ 10 ] ; 
int*  ip  = i; 
double*  dp  = d; 
cout  <<  "ip  = " 
ip++; 

cout  <<  "ip  = " 
cout  <<  "dp  = " 
dp++; 

cout  <<  "dp  = " 
} ///:- 


<<  (long) ip  <<  endl; 

<<  (long) ip  <<  endl; 
<<  (long) dp  <<  endl; 

<<  (long) dp  <<  endl; 


For  one  run  on  my  machine,  the  output  is: 


ip  = 6684124 
ip  = 6684128 
dp  = 6684044 
dp  = 6684052 

What's  interesting  here  is  that  even  though  the  operation  ++ 
appears  to  be  the  same  operation  for  both  theint*and  thedouble* 
you  can  see  that  the  pointer  has  been  changed  only  4 bytes  for  the 
int*  but  8 bytes  for  the  double*.  Not  coincidentally,  these  are  the 
sizes  of  int  and  doubleon  my  machine.  And  that's  the  trick  of 
poi  nter  arithmetic:  the  compiler  figures  out  the  right  amount  to 
change  the  poi  nter  so  that  it's  poi  nti  ng  to  the  next  el  ement  i n the 
array  (pointer  arithmetic  is  only  meaningful  within  arrays).  This 
even  works  with  arrays  of  struck: 


//:  COS : PolnterIncrement2 . cpp 
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#include  <iostream> 
using  namespace  std; 

typedef  struct  { 
char  c; 
short  s; 
int  i ; 
long  1; 
float  f; 
double  d; 
long  double  Id; 

} Primitives; 

int  main  ( ) { 

Primitives  p[10]; 

Primitives*  pp  = p; 

cout  <<  "sizeof (Primitives)  = " 

<<  sizeof (Primitives ) <<  endl; 
cout  <<  "pp  = " <<  (long)pp  <<  endl; 

PP++; 

cout  <<  "pp  = " <<  (long)pp  <<  endl; 

} ///:- 

The  output  for  one  run  on  my  machine  was: 

sizeof (Primitives ) = 40 
pp  = 6683764 
pp  = 6683804 

So  you  can  see  the  compi  I er  al  so  does  the  ri  ght  thi  ng  for  poi  nters  to 
struck  (and  clasps  and  unions). 

Pointer  arithmetic  also  works  with  the  operators +,  and  but  the 
latter  two  operators  are  limited:  you  cannot  add  two  pointers,  and 
if  you  subtract  poi  nters  the  result  isthenumber  of  elements 
between  the  two  pointers.  H owever,  you  can  add  or  subtract  an 
integral  value  and  a pointer.  Here's  an  example  demonstrating  the 
u se  of  poi  nter  ar i th  met!  c: 

// : C03 : PointerArithmetic . cpp 
#include  <iostream> 
using  namespace  std; 
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#define  P (EX)  cout  <<  #EX  <<  " <<  EX  <<  endl; 

int  main  ( ) { 

int  a [ 10 ] ; 

for(int  i = 0;  i < 10;  1++) 

a[i]  =1;  //  Give  it  index  values 

int*  ip  = a; 

P (*ip) ; 

P (*++ip) ; 

P (*  (ip  t 5)  ) ; 
int*  ip2  = ip  + 5; 

P (*ip2) ; 

P (* (ip2  - 4) ) ; 

P (*  — ip2)  ; 

P(ip2  - ip);  //  Yields  number  of  elements 

} ///:- 

It  begins  with  another  macro,  but  this  one  uses  a preprocessor 
feature  cal  led  stringizing  (implemented  with  the'#'  sign  before  an 
expression)  that  takes  any  expression  and  turns  it  into  a character 
array.  Thi  s i s qu  ite  conveni  ent,  si  nee  i t al  I ows  the  expressi  on  to  be 
printed,  followed  by  a colon,  followed  by  the  value  of  the 
expression.  In  main(  )you  can  seethe  useful  shorthand  that  is 
produced. 

Although  pre-  and  postfix  versions  of  ++and  --are  valid  with 
pointers,  only  the  prefix  versions  are  used  in  this  example  because 
they  are  applied  beforethe  pointers  are  dereferenced  in  the 
expressi  ons  above,  so  they  al  I ow  us  to  see  the  effects  of  the 
operations.  Note  that  only  integral  values  are  being  added  and 
subtracted;  if  two  poi  nters  were  combi  ned  thi  sway  the  compiler 
would  notallow  it. 

H ere  is  the  output  of  the  program  above: 

*ip : 0 

*++ip:  1 

* (ip  + 5)  : 6 
*ip2  : 6 

* (ip2  - 4)  : 2 
* — ip2 : 5 
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In  all  cases,  the  pointer  arithmetic  results  in  the  pointer  being 
adjusted  to  point  to  the  "right  place,"  based  on  the  size  of  the 
elements  being  pointed  to. 

If  pointer  arithmetic  seems  a bit  overwhelming  at  first,  don't  worry. 
Most  of  the  time  you'll  only  need  to  create  arrays  and  index  into 
them  with  [ 1 and  the  most  sophisticated  pointer  arithmetic  you'll 
usually  need  is++and  Pointer  arithmetic  is  generally  reserved 
for  more  clever  and  complex  programs,  and  many  of  the  containers 
in  the  Standard  C++library  hidemostof  these  cl  ever  details  so  you 
don't  have  to  worry  about  them. 


Debugging  hints 

In  an  ideal  environment,  you  have  an  excellent  debugger  available 
that  easi  ly  makes  the  behavior  of  your  program  transparent  so  you 
can  quickly  discover  errors.  However,  most  debuggers  have  blind 
spots,  and  these  will  require  you  to  embed  code  snippets  in  your 
program  to  help  you  understand  what'sgoing  on.  In  addition,  you 
may  bedeveloping  in  an  environment  (such  as  an  embedded 
system,  which  is  where  I spent  my  formative  years)  that  has  no 
debugger  available,  and  perhaps  very  limited  feedback  (i.e.  aone- 
lineLED  display).  I n these  cases  you  become  creative  in  theways 
you  discover  and  display  information  about  the  execution  of  your 
program.  This  section  suggests  some  techniques  for  doing  this. 

Debugging  flags 

If  you  hard-wire  debugging  code  into  a program,  you  can  run  into 
problems.  You  start  to  get  too  much  information,  which  makes  the 
bugs  difficult  to  isolate.  When  you  think  you've  found  the  bug  you 
start  tearing  out  debugging  code,  only  to  find  you  need  to  put  it 
back  in  again.  You  can  solvethese  problems  with  two  types  of 
flags:  preprocessor  debugging  flags  and  runtime  debugging  flags. 
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Preprocessor  debugging  flags 

By  using  the  preprocessor  to  #defineoneor  more  debugging  flags 
(preferably  in  a header  file),  you  can  test  a flag  using  an  #ifdef 
statement  and  conditionally  include  debugging  code.  When  you 
think  your  debugging  isfinished,  you  can  simply  #undef the 
flag(s)  and  the  code  will  automatically  be  removed  (and  you'll 
reducethe  size  and  runtime  overhead  of  your  executable  file). 

It  is  best  to  decide  on  namesfor  debugging  flags  before  you  begin 
building  your  project  so  the  names  will  be  consistent.  Preprocessor 
flags  are  traditionally  distinguished  from  variables  by  writing  them 
in  all  uppercase.  A common  flag  name  is  simply  DEBUG  (but  be 
careful  you  don't  use N DEBUG,  which  is  reserved  in  C).The 
sequence  of  statements  might  be: 

#define  DEBUG  //  Probably  in  a header  file 

//.  . . 

#ifdef  DEBUG  //  Check  to  see  if  flag  is  defined 
/*  debugging  code  here  */ 

#endif  //  DEBUG 

MostC  and  C++ implementations  will  also  let  you  #defineand 
#undefflags from  the  compiler  command  line,  so  you  can  re- 
compile code  and  insert  debugging  information  with  a single 
command  (preferably  via  the  makefile,  atool  that  will  be  described 
shortly).  Check  your  local  documentation  for  details. 

Runtime  debugging  fiags 

In  some  situations  it  is  more  convenient  to  turn  debugging  flags  on 
and  off  during  program  execution,  especially  by  setting  them  when 
the  program  starts  up  using  the  command  line.  Large  programs  are 
tediousto  recompile  just  to  insert  debugging  code. 

To  turn  debugging  codeon  and  off  dynamically,  create  bool  flags: 

//:  COS : DynamicDebugFlags . cpp 
#include  <iostream> 

#include  <string> 
using  namespace  std; 
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//  Debug  flags  aren't  necessarily  global: 
bool  debug  = false; 


int  main(int  argc,  char*  argv [ ] ) { 

for(int  1=0;  1 < argc;  1++) 

if (string (argv [1] ) ==  " — debug=on") 
debug  = true; 
bool  go  = true; 
while (go)  { 
if (debug)  { 

//  Debugging  code  here 

cout  <<  "Debugger  is  now  on!"  <<  endl; 

} else  { 

cout  <<  "Debugger  is  now  off."  <<  endl; 

} 

cout  <<  "Turn  debugger  [on/off/quit] : "; 

string  reply; 
cin  >>  reply; 

if (reply  ==  "on")  debug  = true;  //  Turn  it  on 
if (reply  ==  "off")  debug  = false;  //  Off 
if (reply  ==  "quit")  break;  //  Out  of  'while' 

} 

} ///:- 

This  program  continues  to  aiiow  you  to  turn  theciebuggingfiag  on 
anci  off  untii  you  type"quit"  toteii  it  you  want  to  exit.  Notice  it 
requ  ires  that  fuii  worcis  are  typed  in,  notjustietters(you  can 
shorten  it  to  ietter  if  you  wish).  Aiso,  a command-iine  argument  can 
optionaiiy  be  used  to  turn  debugging  on  at  startup  - this  argument 
can  appear  anypi  ace  in  the  command  iine,  si  nee  the  startup  codein 
main(  )iooksataii  the  arguments.  The  testing  isquitesimpie 
because  of  the  express!  on : 

string (argv [1] ) 

This  takes  the  argv[i]character  array  and  creates  a string  which 
then  can  beeasiiy  compared  to  the  right-hand  sideof  the==.  The 
program  above  searches  for  the  enti  re  stri  ng  -debug=on  You  can 
aiso  iook  for  -debug=and  then  see  what's  after  that,  to  provide 
more  opti  ons.  Voi  u me  2 (avai  i abi  e from  www.BruceE ckd. com) 
devotes  a chapter  to  the  Standard  C -h- stri ngei ass. 
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Although  a debugging  flag  isoneof  the  relatively  few  areas  where 
it  makes  a lot  of  sense  to  use  a global  variable,  there's  nothing  that 
says  it  must  be  that  way.  Noticethatthevariableisin  lowercase 
letters  to  remind  the  reader  it  isn't  a preprocessor  flag. 

Turning  variables  and  expressions  into  strings 

When  writing  debugging  code,  it  istediousto  write  print 
express! ons  consi  sti  ng  of  a character  array  contai  ni  ng  the  vari  abl  e 
name,  followed  by  the  vari  able.  Fortunately,  Standard  C includes 
the str/ng/ze operator  '#',  which  wasused  earlier  in  thischapter. 
When  you  put  a # before  an  argument  in  a preprocessor  macro,  the 
preprocessor  turns  that  argument  i nto  a character  array.  This, 
combined  with  thefactthat  character  arrays  with  no  intervening 
punctuation  are  concatenated  into  a single  character  array,  allows 
you  to  make  a very  conveni  ent  macro  for  pri  nti  ng  the  val  ues  of 
variables  during  debugging: 

I #define  PR(x)  cout  <<  #x  " = " <<  x <<  "\n"; 

If  you  print  the  vari  able  a by  cal  ling  the  macro  PR(a),  itwill  have 
the  same  effect  as  the  code: 

I cout  <<  "a  = " <<  a <<  "\n"; 

This  same  process  works  with  entire  expressions.  Thefollowi  ng 
program  uses  a macro  to  create  a shorthand  that  prints  the 
string!  zed  expression  and  then  evaluates  the  express!  on  and  prints 
the  result: 

// : COS : StringizingExpressions . cpp 
#include  <iostream> 
using  namespace  std; 

#define  P (A)  cout  <<  #A  <<  " <<  (A)  <<  endl; 

int  main  ( ) { 

int  a = 1,  b = 2,  c = 3; 

P(a);  P(b);  P(c); 

P (a  + b) ; 
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P ( (c  - a)  /b)  ; 

} III-.- 

You  can  see  how  a technique  I ike  this  can  quickly  become 
indispensable,  especially  if  you  have  no  debugger  (or  must  use 
multi  pie  development  environments).  You  can  also  insert  an  #ifdef 
to  cause  P(A)to  be  defined  as  "nothing"  when  you  want  to  strip 
out  debugging. 

The  C assert(  ) macro 

In  the  standard  header  file  <cassert>you'l  I find  assert( ) which  isa 
convenient  debugging  macro.  When  you  useassert( ) you  give  it 
an  argument  that  is  an  expression  you  are  "asserting  to  be  true." 
The  preprocessor  generates  code  that  will  test  the  assertion.  Ifthe 
assertion  isn'ttrue,  the  program  will  stop  after  issuing  an  error 
message  tel  ling  you  what  the  assertion  was  and  that  it  failed. 

Here's  a trivial  example: 

//:  COS : Assert . cpp 

//  Use  of  the  assert  ()  debugging  macro 
#include  <cassert>  //  Contains  the  macro 
using  namespace  std; 

int  main  ( ) { 

int  i = 100; 

assert  (i  !=  100);  //  Fails 
} ///:- 

The  macro  originated  in  Standard  C,  so  it's  also  available  in  the 
header  fileassert.h 

When  you  are  finished  debugging,  you  can  removethecode 
generated  by  the  macro  by  placing  the  line: 

I #define  NDEBUG 

in  the  program  before  the  inclusion  of  <cassert::^  or  by  defining 
NDEBUG  on  the  compiler  command  line.  NDEBUG  is  a flag  used 
i n <cassert>to  change  the  way  code  i s generated  by  the  macros. 
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Later  in  this  book,  you'll  see  some  more  sophisticated  alternatives 

to  assert( ) 


Function  addresses 

Once  a function  is  compiled  and  loaded  i nto  the  computer  to  be 
executed,  it  occupies  a chunk  of  memory.  That  memory,  and  thus 
the  function,  has  an  address. 

C has  never  been  a language  to  bar  entry  where  others  fear  to  tread. 
You  can  use  function  addresses  with  pointers  just  as  you  can  use 
variable  addresses.  The  declaration  and  use  of  function  pointers 
looks  a bit  opaque  at  first,  but  itfollowstheformatof  therestof  the 
language. 

Defining  a function  pointer 

To  define  a pointer  to  a function  that  has  no  arguments  and  no 
return  value,  you  say: 

I void  (*funcPtr)  (); 

When  you  are  looking  at  a complex  definition  likethis,  the  best 
way  to  attack  i t i s to  start  inthemiddleandwork  you  r way  out. 
"Starting  in  the  middle"  means  start!  ng  at  the  variable  name,  which 
i s f u ncPtr  "Work!  ng  your  way  out"  means  I ooki  ng  to  the  ri ght  for 
the  nearest  item  (nothing  in  this  case;  the  right  parenthesis  stops 
you  short),  then  looking  to  the  left  (a  pointer  denoted  by  the 
asterisk),  then  looking  to  the  right  (an  empty  argument  list 
indicating  a function  that  takes  no  arguments),  then  looking  to  the 
left  (void, which  indicates  the  function  has  no  return  value).  This 
right-left-right  motion  works  with  most  declarations. 

To  review,  "start  in  the  middle"  ("funcPtris  a ..."),  go  to  the  right 
(nothing  there  - you're  stopped  by  the  right  parenthesis),  go  to  the 
left  and  find  the'*'  ("...  pointer  to  a ..."),  goto  the  right  and  find  the 
empty  argument  list  ("...  function  that  takes  no  arguments ...  "),  go 
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to  the  left  and  find  the  void  ("funcPtris  a pointer  to  a function  that 
takes  no  arguments  and  returns  void"). 


You  may  wonder  why  *funcPtrrequires  parentheses.  If  you  didn't 
use  them,  the  compiler  would  see: 

I void  *funcPtr(); 

You  would  be  declaring  a function  (that  returns  a void*)  rather 
than  defi  ni  ng  a vari  abl  e.  Y ou  can  thi  nk  of  the  compi  I er  as  goi  ng 
through  the  same  process  you  do  when  it  figures  out  what  a 
declaration  or  definition  is  supposed  to  be.  It  needs  those 
parentheses  to  "bump  up  against"  so  it  goes  back  to  the  left  and 
finds  the'*',  instead  of  continuing  to  the  right  and  finding  the 
empty  argument  list. 

Complicated  declarations  & definitions 

As  an  aside,  once  you  figure  out  how  theC  and  C++ declaration 
syntax  works  you  can  create  much  more  complicated  items.  For 
i nstance: 


// : COS : Compi icatedDefinit ions . cpp 


/* 

1 . 

*/ 

void  * 

(* (*fpl)  (int) ) [10]  ; 

/* 

2 . 

*/ 

float  ( 

*(*fp2)  ( int , int , float ) ) (int); 

/* 

3. 

*/ 

typedef 

double  (* (* (*fp3)  () ) [10] ) () ; 

fp3  a; 

/* 

4 . 

*/ 

int  (*  ( 

*f4  0 ) [10]  ) 0 ; 

int  main  ( ) { } ///  : ~ 

Walkthrough  each  one  and  use  the  right-left  guideline  to  figureit 
out.  N umber  1 says  "fpl  is  a pointer  to  a function  that  takes  an 
integer  argument  and  returns  a pointer  to  an  array  of  10  void 
pointers." 
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N umber  2 says  "fp2  is  a pointer  to  a function  that  takes  three 
argu  ments  (inti  nt,  and  f i oat  and  retu  rns  a poi  nter  to  a f u ncti  on 
that  takes  an  integer  argument  and  returns  a fioat" 

If  you  are  creating  a lot  of  complicated  definitions,  you  might  want 
to  use  a ty pedef  N u mber  3 shows  how  a typedef  saves  ty pi  ng  the 
complicated  description  every  time.  It  says  "Anfp3isa  poi  nter  toa 
function  that  takes  no  arguments  and  returns  a pointer  to  an  array 
of  10  pointers  to  functions  that  take  no  arguments  and  return 
doubles."  Then  it  says  "a  i s one  of  these  fp3  types."  typedef  is 
generally  useful  for  building  complicated  descriptions  from  simple 
ones. 

Number  4 is  a function  declaration  instead  of  a variable  definition. 
It  says  "f4  is  a function  that  returns  a poi  nter  to  an  array  of  10 
pointers  to  functions  that  return  integers." 

You  will  rarely  if  ever  need  such  complicated  declarations  and 
definitions  as  these.  However,  if  you  go  through  the  exercise  of 
figuring  them  out  you  will  not  even  be  mildly  disturbed  with  the 
slightly  complicated  ones  you  may  encounter  in  real  life. 

Using  a function  pointer 

Once  you  define  a pointer  to  a function,  you  must  assign  ittoa 
function  address  before  you  can  useit.Justastheaddressof  an 
array  arr[10]is  produced  by  the  array  name  without  the  brackets 
(arr),  the  address  of  a function  funcQis  produced  by  the  function 
name  without  the  argument  list  (func).  You  can  also  use  the  more 
explicit  syntax &func()  To  call  thefunction,  you  dereference  the 
pointer  in  the  same  way  that  you  declared  it  (remember  that  C and 
C++ always  try  to  make  defi  nitions  look  the  same  as  the  way  they 
are  used).  The  foil  owing  example  shows  how  a pointer  to  a 
function  is  defined  and  used: 

//:  COS : PointerToFunction . cpp 

//  Defining  and  using  a pointer  to  a function 
#include  <iostream> 
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using  namespace  std; 


void  f unc ( ) { 

cout  <<  "funcO  called..."  <<  endl; 

} 

int  main  ( ) { 

void  (*fp)  0;  //  Define  a function  pointer 

fp  = func;  //  Initialize  it 

(*fp)  0;  //  Dereferencing  calls  the  function 

void  (*fp2)  0 = func;  //  Define  and  initialize 
(*fp2)  0 ; 

} ///:- 

After  the  pointer  to  function  fp  is  defined,  it  is  assigned  to  the 
address  of  a function  funcQ  using  fp  = func(  notice  the  argument 
ii  St  is  missing  on  the  function  name).  The  second  case  shows 
si muitaneous definition  and  initiaiization. 

Arrays  of  pointers  to  functions 

One  of  the  more  i nteresti  ng  constructs  you  can  create  i s an  array  of 
pointers  to  functions.  To  seiect  a function,  you  just  index  into  the 
array  and  dereference  the  pointer.  This  supports  the  concept  of 
table-driven  code,  instead  of  using  conditionaisor  case  statements, 
you  seiect  functions  to  execute  based  on  a statevariabie(or  a 
combination  of  state  variabies).  This  kind  of  design  can  beusefui  if 
you  often  add  or  deiete  functions  from  thetabie(or  if  you  want  to 
create  or  change  such  a tabie  dynamicai  iy). 

The  foii  owing  exampie  creates  some  dummy  functions  using  a 
preprocessor  macro,  then  creates  an  array  of  pointers  to  those 
functions  using  automatic  aggregate  initiaiization.  As  you  can  see, 
it  is  easy  to  add  or  remove  functions  from  the  tabie  (and  thus, 
functionaiity  from  the  program)  by  changing  a smaii  amount  of 
code: 

//:  COS : FunctionTable . cpp 

//  Using  an  array  of  pointers  to  functions 
#include  <iostream> 
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using  namespace  std; 


//  A macro  to  define  dummy  functions: 

#define  DF (N)  void  N()  { \ 

cout  <<  "function  " #N  " called. . <<  endl;  } 

DF(a);  DF(b);  DF(c);  DF (d) ; DF(e);  DF(f);  DF (g) ; 

void  (*func_table [ ] ) ()  = { a,  b,  c,  d,  e,  f,  g }; 

int  main  ( ) { 

while ( 1 ) { 

cout  <<  "press  a key  from  'a'  to  'g'  " 

"or  q to  quit"  <<  endl; 
char  c,  cr; 

cin.get(c);  cin.get(cr);  //  second  one  for  CR 
if  ( c ==  'q'  ) 

break;  //  ...  out  of  while  (1) 
if  ( c < 'a'  I I c > 'g'  ) 
continue; 

(*func_table  [c  - 'a'])  0; 

} 

} ///:- 

At  this  point,  you  might  be  abie  to  imagine  how  this  technique 
couid  beusefui  when  creating  somesort  of  interpreter  or  iist 
processing  program. 


Make;  managing  separate 
compilation 

When  using  separate  compilation  (breaking  code  into  a number  of 
transiation  units),  you  need  someway  to  automaticaiiy  compiie 
each  fiieand  toteii  the  i inker  to  bui  id  aii  the  pieces- aiong  with  the 
appropriate  iibraries and  startup  code-  into  an  executabiefiie. 
Mostcompiiersaiiow  you  todothiswith  asingiecommand-iine 
statement.  For  the  GNU  C-H-compiier,  forexampie,  you  might  say 

I g++  SourceFilel . cpp  SourceFile2 . cpp 
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The  probi  em  wi  th  thi  s approach  i s that  the  compi  I er  w i 1 1 f i rst 
compileeach  individual  file,  regardless  of  whether  that  file  needs  to 
be  rebuilt  or  not.  With  many  files  in  a project,  it  can  become 
prohibitiveto  recompile  everything  if  you've  changed  only  a single 
file. 

The  solution  to  this  problem,  developed  on  Unix  but  available 
everywhere  in  some  form,  is  a program  called  make  The  make 
utility  manages  all  the  individual  files  in  a project  by  following  the 
instructions  in  a text  file  cal  led  a makefile  When  you  edit  some  of 
the  files  in  a project  and  type  make  the  make  program  follows  the 
gui  del  i nes  i n the  makef  i leto  compare  the  dates  on  the  source  code 
fi  les  to  the  dates  on  the  correspond!  ng  target  fi  les,  and  if  a source 
code  f i I e date  i s more  recent  than  its  target  f i I e,  make  i nvokes  the 
compiler  on  the  source  code  file,  makeonly  recompiles  the  source 
codefilesthat  were  changed,  and  any  other  source-code  files  that 
are  affected  by  the  modified  files.  By  using  make  you  don't  have  to 
re-compile  all  the  files  in  your  project  every  time  you  make  a 
change,  nor  do  you  haveto  check  to  see  that  everything  was  built 
properly.  The  makefilecontai  ns  all  the  commands  to  put  your 
project  together.  Learning  to  use  make  will  saveyou  a lot  of  time 
and  frustration.  You'll  also  discover  that  make  is  the  typical  way 
that  you  install  new  software  on  a Linux/  Unix  machine  (although 
those  makefile  tend  to  be  far  more  complicated  than  the  ones 
presented  in  this  book,  and  you'll  often  automatically  generate  a 
makef  i I efor  you r parti cu I ar  mach i ne  as  part  of  the  i nstal  I ati on 
process). 

Because  make  is  available  in  some  form  for  virtually  all  C-h- 
compilers  (and  even  if  it  isn't,  you  can  usefreely-avai  I able  makes 
with  any  compiler),  it  will  be  the  tool  used  throughout  this  book. 
However,  compiler  vendors  have  also  created  their  own  project 
bu  i I d i ng  tool  s.  These  tool  s ask  you  w h i ch  f i I es  are  i n you  r project 
and  determine  all  the  relationshipsthemselves.  These  tools  use 
something  similar  to  a makef  Me  generally  called  a project  file,  but 
the  programming  environment  maintains  this  file  so  you  don't 
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have  to  worry  about  it.  The  configuration  and  use  of  project  files 
varies  from  one  development  environment  to  another,  so  you  must 
find  the  appropriate  documentation  on  how  to  use  them  (although 
project  file  tools  provided  by  compiler  vendors  are  usually  so 
simple  to  use  that  you  can  learn  them  by  playing  around  - my 
favorite  form  of  education). 

The  makefiles  used  within  this  book  should  work  even  if  you  are 
also  using  a specific  vendor's  project-building  tool. 

Make  activities 

When  you  type  make  (or  whatever  the  name  of  your  "make" 
program  happens  to  be),  the  make  program  looks  in  the  current 
directory  for  a file  named  makefile  which  you've  created  if  it's 
your  project.  Thisfilelistsdependencies  between  source  codefiles, 
make  looks  at  the  dates  on  files.  If  a dependent  file  has  an  older 
date  than  a file  it  depends  on,  makeexecutes  the  ru/e  given  after  the 
dependency. 

All  comments  in  makefiles  start  with  a#  and  continue  to  the  end  of 
the  line. 

Asa  simple  example,  themakefilefor  a program  called  "hello" 
might  contain: 

# A comment 
hello.exe:  hello. cpp 

mycompiler  hello. cpp 

This  says  that  hello.exe(the  target)  depends  on  hello.cpp  When 
hello.cpphas  a newer  date  than  hello.exe  make  executes  the 
"rule"  mycompiler  hello.cppTheremay  be  multi  pie  dependencies 
and  multiple  rules.  Many  make  programs  require  that  all  the  rules 
begin  with  atab.  Other  than  that,  whitespace  is  generally  ignored 
so  you  can  format  for  readabi  I ity. 
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The  rules  are  not  restricted  to  being  cal  Is  to  the  compiler;  you  can 
call  any  program  you  want  from  within  make  By  creating  groups 
of  interdependent  dependency-rule  sets,  you  can  modify  your 
source  codefiles,  type  makeand  be  certain  that  all  the  affected  files 
will  be  rebuilt  correctly. 

Macros 

A makefi I emay  contain  macros  (notethat  these  are  completely 
different  from  C/  C-H- preprocessor  macros).  Macrosallow 
convenient  string  replacement.  The  makefiles  in  this  book  use  a 
macro  to  invoke  the  C-H- compiler.  For  example, 

CPP  = mycompiler 
hello.exe:  hello. cpp 

$ (CPP)  hello. cpp 

The  = is  used  to  identify  CPP  as  a macro,  and  the  $ and  parentheses 
expand  the  macro.  I n this  case,  the  expansion  means  that  the  macro 
call  $(CPP)will  be  replaced  with  the  string  mycompiler  With  the 
macro  above,  if  you  want  to  change  to  a different  compiler  cal  led 
cpp,  you  just  change  the  macro  to: 

CPP  = cpp 

You  can  also  add  compiler  flags,  etc,  to  the  macro,  or  use  separate 
macros  to  add  compi  ler  flags. 

Suffix  Rules 

It  becomes  tedious  to  tel  I makehow  to  invoke  the  compi  ler  for 
every  singlecppfile  in  your  project,  when  you  know  it'sthesame 
basi  c process  each  ti  me.  Si  nee  make  i s desi  gned  to  be  a ti  me-saver, 
it  also  has  a way  to  abbreviate  actions,  as  long  as  they  depend  on 
fi  le  name  suffixes.  These  abbreviations  are  cal  led  suffix  rules.  A 
suffix  rule  is  the  way  to  teach  makehow  to  convert  a file  with  one 
type  of  extension  (.cpp,  for  example)  into  a file  with  another  type  of 
extension  (.obj  or  .exe).  Once  you  teach  makethe  rules  for 
producing  one  kind  of  file  from  another,  all  you  have  to  do  is  tel  I 
makewhich  files  depend  on  which  other  files.  When  makefi  ndsa 
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file  with  a date  earlier  than  the  file  it  depends  on,  it  uses  the  rule  to 
create  a new  file. 

The  suffix  ruletellsmakethat  it  doesn't  need  explicit  rules  to  build 
everything,  but  instead  it  can  figure  out  how  to  build  things  based 
on  thei  r f i I e extensi  on . I n thi s case  it  says  "To  bu i I d a f i I e that  end s 
in  exefrom  one  that  ends  in  cpp,  invoke  the  foil  owing  command." 
Here's  what  it  looks  likefor  the  example  above: 

CPP  = mycompiler 
.SUFFIXES:  . exe  .cpp 

. cpp . exe : 

$(CPP)  $< 

The  .SUFFIXESdirectivetel  Is  makethat  it  should  watch  out  for 
any  of  the  fol  I ow  i ng  f i I e-name  extensi  ons  because  they  have  sped  al 
meaning  for  this  particular  makefile.  Next  you  seethe  suffix  rule 
.cpp.exe, which  says  "Here's  how  to  convert  any  file  with  an 
extension  of  cpp  to  one  with  an  extension  of  exe"  (when  the  cpp  file 
is  more  recent  than  the  exe  file).  As  before,  the  $(CPP)  macro  is 
used,  but  then  you  see  something  new:  $<  Because  this  begins  with 
a'$'  it's  a macro,  but  this  is  one  of  makefs  special  built-in  macros. 
The  $<  can  be  used  only  in  suffix  rules,  and  it  means  "whatever 
prerequisite  triggered  the  rule"  (sometimes  cal  led  the  dependent), 
which  in  this  case  translates  to  "the  cpp  file  that  needs  to  be 
compiled." 

Once  the  suffix  rules  have  been  set  up,  you  can  simply  say,  for 
example,  "make  Union  .ex0'  and  the  suffix  rulewill  kick  in,  even 
though  there's  no  mention  of  "Union"  anywhere  in  the  makefile 

Default  targets 

After  the  macros  and  suffix  rules,  make  looks  for  the  first  "target" 
in  afile,  and  builds  that,  unless  you  specify  differently.  So  for  the 
following  makefile 

CPP  = mycompiler 
.SUFFIXES:  .exe  .cpp 

. cpp . exe : 
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$(CPP)  $< 
target  1 . exe : 
target2 . exe : 

If  you  just  type  'make^,  then  targetLexewi  II  be  bui  It  (usi  ng  the 
default  suffix  rule)  because  that's  the  first  target  that  make 
encounters.  To  build  target2.exeyou'd  haveto  explicitly  say  'make 
target2.exa.  This  becomes  tedious,  so  you  normally  create  a default 
"dummy"  target  that  depends  on  all  the  rest  of  the  targets,  likethis: 

CPP  = mycompiler 
.SUFFIXES:  .exe  . cpp 

. cpp . exe : 

$(CPP)  $< 

all:  targetl.exe  target2.exe 

Here,  'all'  does  not  exist  and  there's  no  file  cal  led  'all',  so  every 
ti  me  you  type  maket  the  program  sees  'all'  as  the  fi  rst  target  i n the 
list  (and  thus  the  default  target),  then  it  sees  that 'all'  does  not  exist 
so  it  had  better  make  it  by  checking  all  the  dependencies.  So  it  looks 
at  targetLexeand  (using  the  suffix  rule)  sees  whether  (1) 
targetl.exeexists  and  (2)  whether  targetLcppis  more  recent  than 
targetLexaand  if  so  runs  the  suffix  rule  (if  you  provide  an  explicit 
rule  for  a particular  target,  that  rule  is  used  instead).  Then  it  moves 
on  to  the  next  fi  le  in  the  default  target  I ist.  Thus,  by  creati ng  a 
default  target  list  (typically  called  'all'  by  convention,  but  you  can 
call  it  anything)  you  can  cause  every  executable  in  your  project  to 
be  made  simply  by  typing  'mak^.  In  addition,  you  can  have  other 
non-default  target  lists  that  do  other  things  - for  example,  you 
could  set  it  up  so  that  typing  'make  debug  rebuilds  all  your  files 
with  debugging  wired  in. 

Makefiles  in  this  book 

U si  ng  the  program  ExtractC  odexppfrom  Vol  u me  2 of  th  i s book, 
al  I the  code  I i sti  ngs  i n thi  s book  are  automati cal  ly  extracted  from 
the  ASCI  I text  version  of  this  book  and  placed  in  subdirectories 
according  to  thei r chapters.  I n addition,  ExtractC ode.cppcreates 
several  makefiles  in  each  subdirectory  (with  different  names)  so 
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you  can  si  mply  move  i nto  that  subdirectory  and  type  make  -f 
mycompiler.makefilcisubstituti  ng  the  name  of  your  compiler  for 
'mycompile^,  the'-f  flag  says  "use  what  follows  as  the 
makefile').  Finally,  ExtractCode.cppcreates a "master"  makefile 
in  the  root  directory  where  the  book's  files  have  been  expanded, 
and  thismakefiledescends  into  each  subdirectory  and  cal  Is  make 
with  the  appropriate  makefileThis  way  you  can  compileall  the 
code  in  the  book  by  invoking  a single  makecommand,  and  the 
process  will  stop  whenever  your  compiler  isunableto  handlea 
parti cu I ar  f i I e (note  that  a Stand ard  C ++  conform!  ng  compi  I er 
should  be  able  to  compileall  the  files  in  this  book).  Because 
i mplementations  of  make  vary  from  system  to  system,  only  the 
most  basic,  common  features  are  used  i n the  generated  makefileB. 

An  example  makefile 

As  mentioned,  the  code-extraction  tool  ExtractCode.cpp 
automatically  generates  makefiles  for  each  chapter.  Because  of  this, 
the  makefiles  for  each  chapter  will  not  be  placed  in  the  book  (all 
the  makefiles  are  packaged  with  the  source  code,  which  you  can 
download  from  www.BruceEckd.com).  However,  it's  useful  to  see  an 
exampleof  a makefile  What  follows  Isa  shortened  version  of  the 
one  that  was  automatically  generated  for  this  chapter  by  the  book's 
extraction  tool.  You'll  find  more  than  one  makef  Mein  each 
subdirectory  (they  have  different  names;  you  invoke  a specific  one 
with  'make -f).  This  one  is  for  GNU  C-H-: 

CPP  = g++ 

OFLAG  = -o 

.SUFFIXES  : .o  . cpp  .c 

. cpp . o : 

$(CPP)  $(CPPFLAGS)  -c  $< 

. c . o : 

$(CPP)  $(CPPFLAGS)  -c  $< 

all:  \ 

Return  \ 

Declare  \ 

Ifthen  \ 
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Guess  \ 

Guess2 

# Rest  of  the  files  for  this  chapter  not  shown 

Return:  Return. o 

$(CPP)  $ (OFLAG) Return  Return. o 

Declare:  Declare,  o 

$(CPP)  $ (OFLAG) Declare  Declare. o 

Ifthen:  Ifthen.o 

$(CPP)  $ (OFLAG) Ifthen  Ifthen.o 

Guess:  Guess,  o 

$(CPP)  $ (OFLAG) Guess  Guess. o 

Guess2:  Guess2.o 

$(CPP)  $ (OFLAG) Guess2  Guess2.o 

Return. o:  Return. cpp 
Declare. o:  Declare. cpp 
Ifthen.o:  Ifthen. cpp 
Guess. o:  Guess. cpp 
Guess2.o:  Guess2.cpp 

The  macro  CPP  is  set  to  the  name  of  the  compiler.  To  use  a different 
compiler,  you  can  either  edit  the  makefileor  change  the  value  of 
the  macro  on  the  command  I i ne,  I i ke  this: 

make  CPP=cpp 

Note,  however,  that  ExtractCode.cpphas  an  automatic  scheme  to 
automatically  build  makefiles  for  additional  compilers. 

The  second  macro  OFLAG  is  the  flag  that's  used  to  indicate  the 
nameof  the  output  file.  Although  many  compilers  automatically 
assu  me  the  output  fi  I e has  the  same  base  name  as  the  i nput  f 1 1 e, 
othersdon't  (such  as  Linux/  Unix  compilers,  which  default  to 
creating  a file  cal  led  a.ou^. 

You  can  see  that  there  are  two  suffix  rules  here,  one  for  cpp  files 
and  one  for  .c  files  (in  case  any  C source  code  needs  to  be 
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compiled).  The  default  target  isall,  and  each  line  for  this  target  is 
"continued"  by  using  the  backslash,  up  until  Guess2  which  isthe 
last  one  in  the  list  and  thus  has  no  backslash.  There  are  many  more 
files  in  this  chapter,  but  only  these  are  shown  herefor  thesakeof 
brevity. 

The  suffix  rules  take  care  of  creating  object  files  (with  a .o 
extension)  from  cpp files,  but  in  general  you  need  to  explicitly  state 
rules  for  creating  the  executable,  because  normally  an  executable  is 
created  by  linking  many  different  object  files  and  makecannot 
guess  what  those  are.  Also,  in  this  case  (Linux/  Unix)  there  is  no 
standard  extension  for  executables  so  a suffix  rule  won't  work  for 
these  simplesituations.  Thus,  you  see  all  the  rules  for  building  the 
final  executables  explicitly  stated. 

Thismakefiletakestheabsolutesafest  route  of  using  as  few  make 
features  as  possible;  it  only  uses  the  basic  makeconcepts  of  targets 
and  dependencies,  as  well  as  macros.  This  way  it  is  virtually 
assured  of  working  with  as  many  makeprograms  as  possible.  It 
tends  to  produce  a larger  makefile  but  that's  not  so  bad  since  it's 
automatically  generated  by  ExtractCode.cpp 

There  are  lots  of  other  makefeatures  that  this  book  will  not  use,  as 
well  as  newer  and  cleverer  versions  and  variations  of  makewith 
advanced  shortcuts  that  can  save  a lot  of  time.  Your  local 
documentation  may  describe  the  further  features  of  your  particular 
make  and  you  can  learn  more  about  makefrom  M anaging  Projects 
with  M akeby  Oram  and  Talbott  (O'Reilly,  1993).  Also,  if  your 
compi  ler  vendor  does  not  supply  a makeor  it  uses  a non-standard 
maka  you  can  find  GNU  makefor  virtually  any  platform  in 
existence  by  searchi  ng  the  I nternet  for  GN  U archives  (of  which 
there  are  many). 
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Summary 

This  chapter  was  a fairly  intense  tour  through  all  the  fundamental 
features  of  C++ syntax,  most  of  which  are  inherited  from  and  in 
common  with  C (and  result  in  C++'s  vaunted  backwards 
compatibility  with  C).  Although  some  C++ features  were 
introduced  here,  thistour  is  primarily  intended  for  people  who  are 
conversant  in  programming,  and  simply  need  to  be  given  an 
introduction  to  the  syntax  basics  of  C and  C++.  If  you're  already  a 
C programmer,  you  may  have  even  seen  one  or  two  thi  ngs  about  C 
here  that  were  u nfami  I i ar,  asi  de  from  the  C ++featu  res  that  were 
most  likely  new  to  you.  However,  if  thischapter  has  still  seemed  a 
bit  overwhelming,  you  should  go  through  the  CD  ROM  course 
Thinking  in  C:  Foundations  for  C++  and  Java  (which  contains  lectures, 
exercises,  and  guided  solutions),  which  is  bound  into  this  book,  and 
also  availableat  www.Bruc^ckei.com. 


Exercises 

Solutions  to  selected  exercises  can  be  found  in  the  electronic  document  TheThinking  in  C++ Annotated 
Solution  Guide,  aval  I able  for  a small  feefromwww.BruceEckel.com. 

1.  Createa  header  file  (with  an  extension  of '.h').  In  thisfile, 
declare  a group  of  functions  by  varyi  ng  the  argument 
lists  and  return  values  from  among  the  foil  owing:  void, 
char,  int  and  float  Now  createa  xpp  file  that  includes 
your  header  file  and  creates  definitions  for  all  of  these 
functions.  Each  definition  should  simply  print  out  the 
function  name,  argument  list,  and  return  type  so  you 
know  it's  been  called.  Createa  second  .cpp  file  that 
includes  your  header  fileand  definesint  main( ) 
containing  cal  Is  to  all  of  your  functions.  Compileand  run 
your  program. 

2.  Write  a program  that  uses  two  nested  for  loops  and  the 
modulus  operator  (%)  to  detect  and  print  prime  numbers 
(integral  numbers  that  are  not  evenly  divisible  by  any 
other  numbers  except  for  themselves  and  1). 
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3.  Write  a program  that  usesa  whileloop  to  read  words 
from  standard  input  (cin)  into  a string  This  is  an 
"infinite"  whileloop,  which  you  break  out  of  (and  exit 
the  program)  using  a break  statement.  For  each  word 
that  is  read,  evaluate  it  by  first  using  a sequence  of  if 
statements  to  "map"  an  integral  value  to  the  word,  and 
then  use  a switch  statement  that  uses  that  integral  value 
as  its  selector  (this  sequence  of  events  is  not  meant  to  be 
good  programming  style;  it's  just  supposed  to  give  you 
exercisewith  control  flow).  Insideeach  casa  print 
something  meaningful.  You  must  decide  what  the 
"interesting"  wordsareand  what  the  meaning  is.  You 
must  also  decide  what  word  will  signal  the  end  of  the 
program.  Test  the  program  by  redirecting  a file  into  the 
program's  standard  input  (if  you  want  to  save  typing, 
thisfilecan  be  your  program's  source  file). 

4.  M odify  M enu.cppto  use  switch  statements  instead  of  if 
statements. 

5.  Write  a program  that  evaluates  the  two  expressions  in 
the  section  labeled  "precedence." 

6.  Modify  YourPets2.cppso  that  it  uses  various  different 
data  types  (char,  int  float  double, and  their  variants). 
Run  the  program  and  create  a map  of  the  resulting 
memory  layout.  If  you  have  access  to  more  than  one  kind 
of  machine,  operating  system,  or  compiler,  try  this 
experiment  with  as  many  variations  as  you  can  manage. 

7.  Create  two  functions,  onethattakesastring*and  one 
that  takes  a string&.  Each  of  these  functions  should 
modify  the  outside  string  object  in  its  own  unique  way. 

In  main( ) create  and  initializeastringobject,  print  it, 
then  pass  itto  each  of  the  two  functions,  printing  the 
results. 

8.  Write  a program  that  uses  all  thetrigraphstoseeif  your 
compi  ler  supports  them. 
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9.  Compile  and  run  Staticxpp  Remove  the  static  keyword 
from  the  code,  compile  and  run  it  again,  and  explain 
what  happens. 

10.  Try  to  compile  and  link  FileStaticxppwith 
FileStatic2xppWhat  does  the  resulting  error  message 
mean? 

11.  Modify  Bool  eanxppso  that  it  works  with  doublevalues 
instead  of  ints. 

12.  Modify  Booleanxppand  Bitwisexppsothey  usethe 
expl  icit  operators  (if  your  compi  ler  is  conformant  to  the 
C++ Standard  itwill  support  these). 

13.  Modify  Bitwisexppto  use  the  functions  from 
Rotationxpp  Make  sure  you  display  the  results  in  such  a 
way  that  it's  clear  what's  happening  during  rotations. 

14.  M odify  Ifthenxppto  use  the  ternary  if-elseoperator  (?:). 

15.  Create  a structthat  holds  two  stringobjects  and  oneint 
U se  a typedef  for  the  structname.  C reate  an  i nstance  of 
the  struct  initialize  all  three  values  in  your  instance,  and 
print  them  out.  Taketheaddressof  your  instance  and 
assign  ittoa  pointertoyourstructtype.  Change  the 
three  values  in  your  instance  and  print  them  out,  all 
using  the  pointer. 

16.  Create  a program  that  uses  an  enumeration  of  colors. 
Createa  vari  able  of  this  en  unity  pe  and  print  out  all  the 
numbers  that  correspond  with  the  color  names,  using  a 
for  loop. 

17.  Experiment  with  Unlonxppby  removing  various  union 
el  ements  to  see  the  effects  on  the  si  ze  of  the  resu  I ti  ng 
union.  Try  assigning  to  one  element  (thus  one  type)  of 
the  union  and  printing  out  a via  a different  element  (thus 
a different  type)  to  see  what  happens. 

18.  C reate  a program  that  d efi  nes  two  I nt  arrays,  one  ri ght 
after  the  other.  I ndex  off  the  end  of  the  fi  rst  array  i nto  the 
second,  and  make  an  assignment.  Print  out  the  second 
array  to  seethe  changes  cause  by  this.  N ow  try  defi  ning  a 
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char  variable  between  the  first  array  definition  and  the 
second,  and  repeat  the  experi  ment.  You  may  want  to 
create  an  array  printing  function  to  simplify  your  coding. 

19.  M odify  ArrayAddresses.cpfto  work  with  the  data  types 

char  long  int float, and  double 

20.  Apply  thetechnique  in  ArrayAddresses.cp|to  printout 
the  size  of  the  structand  the  add  resses  of  the  array 
elements  in  StructArray.cpp 

21.  Create  an  array  of  string  objects  and  assign  a string  to 
each  element.  Print  out  the  array  using  a for  loop. 

22.  Createtwonew  programs  starting  from  A rgsToInts.cpp 
so  they  useatol(  )and  atof( ) respectively. 

23.  M odify  Pointerlncrement2.cp|So  it  uses  a union  instead 
of  a struct 

24.  Modify  Pol nterArithmetic.cppo  work  with  longand 
long  double 

25.  Defi  ne  a f I oatvari  abl  e.  T ake  its  add ress,  cast  that  add  ress 
to  an  unsigned  char  and  assign  it  to  an  unsigned  char 

pointer.  Using  this  pointer  and  [ 1 index  into  the  float 
variable  and  use  the  printBi  nary  ( Jfunction  defined  in 
this  chapter  to  print  out  a map  of  thefloat(go  from  0 to 
si zeof (float).  Changethevalueof  thefloatand  see  if 
you  can  figure  out  what's  going  on  (thefloatcontains 
encoded  data). 

26.  Definean  array  of  int  Take  the  starting  address  of  that 
array  and  usestatic_castto  convert  it  into  an  void*. 

Write  a function  that  takes  a void*  a number  (indicating 
a number  of  bytes),  and  a value(indicatingthevalueto 
which  each  byte  should  beset)  as  arguments.  The 
function  should  set  each  byte  in  the  specified  range  to  the 
specified  value.  Try  out  the  function  on  your  array  of  int 

27.  Create  a constarray  of  doubleand  avolatilearray  of 
double  Index  through  each  array  and  useconst_castto 
cast  each  element  to  non-constand  non-volatile 
respectively,  and  assign  a valueto  each  element. 
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28.  C reate  a f u ncti  on  that  takes  a poi  nter  to  an  array  of 
doubi eand  a val  ue  i nd i cati  ng  the  size  of  that  array.  The 
f u ncti  on  shou  I d pri  nt  each  el  ement  i n the  array.  N ow 
create  an  array  of  doubi  eand  initialize  each  el  ement  to 
zero,  then  use  your  function  to  print  the  array.  Next  use 
rei  nterp  ret_  casto  cast  th  e start!  n g ad  d ress  of  you  r array 
to  an  unsigned  char* and  set  each  byte  of  the  array  to  1 
(hint:  you'll  need  to  use  sizeofto  calculate  the  number  of 
bytes  in  adoubld.  Now  use  your  array-printing  function 
to  print  the  results.  Why  do  you  think  each  element  was 
not  set  to  the  val  ue  1.0? 

29.  (Challenging)  Modify  FloatingAsBinary.cpiso  that  it 
prints  out  each  part  ofthedoubleas  a separate  group  of 
bits.  You'll  have  to  replace  the  cal  Is  to  printBinary(  )with 
your  own  specialized  code  (which  you  can  derive  from 
printBinary( ) in  order  to  do  this,  and  you'll  also  have  to 
look  up  and  understand  the  floating-point  format  along 
with  the  byte  ordering  for  your  compiler  (this  is  the 
challenging  part). 

30.  Create  a makefile  that  not  only  compiles  You  rPetsl.cpp 
and  YourPets2.cpp(for  your  particular  compiler)  but 
also  executes  both  programs  as  part  of  the  default  target 
behavior.  Makesureyou  use  suffix  rules. 

31.  M odify  String!  zingExpressions.cppo  that  P(A)  is 
conditionally  #ifdefed  to  allow  the  debugging  code  to  be 
automatically  stripped  out  by  setting  a command-line 
flag.  You  will  need  to  consult  your  compiler's 
documentation  to  see  how  to  defineand  undefine 
preprocessor  values  on  the  compiler  command  line. 

32.  Define  a function  that  takes  a doubleargument  and 
returns  an  int  Create  and  initialize  a pointer  to  this 
function,  and  call  thefunction  through  your  pointer. 

33.  Declare  a poi  nter  to  a function  taking  an  int  argument 
and  returning  a poi  nter  to  a function  that  takes  a char 
argument  and  returns  a float 
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34.  Modify  FunctionTable.cppBO  that  each  function  returns 
a string  (instead  of  printing  out  a message)  and  so  that 
this  value  is  printed  inside  of  main( ) 

35.  Create  a makefilefor  one  of  the  previous  exercises  (of 
your  choice)  that  allows  you  to  type  makefor  a 
production  build  of  the  program,  and  make  debugfor  a 
build  of  the  program  including  debugging  information. 
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4:  Data  Abstraction 

C++  is  a productivity  enhancement  tool.  Why  else  ? 
would  you  make  the  effort  (and  it  is  an  effort, 
regardless  of  how  easy  we  attempt  to  make  the 
transition) 
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to  switch  from  some  language  that  you  already  know  and  are 
productive  with  to  a new  language  in  which  you're  going  to  be  less 
productivefor  a while,  until  you  get  the  hang  of  it?  It's  because 
you've  become  convi  need  that  you're  goi  ng  to  get  bi g gai  ns  by 
using  this  new  tool. 

Productivity,  in  computer  programming  terms,  means  that  fewer 
people  can  make  much  more  complex  and  impressive  programs  in 
less  time.  There  are  certainly  other  issues  when  it  comes  to 
choosing  a language,  such  as  efficiency  (does  the  nature  of  the 
language  cause  slowdown  and  code  bloat?),  safety  (does  the 
language  help  you  ensure  that  your  program  will  always  do  what 
you  plan,  and  handle  errors  gracefully?),  and  maintenance  (does 
the  language  help  you  create  code  that  is  easy  to  understand, 
modify,  and  extend?).  These  are  certainly  i mportant  factors  that 
will  be  examined  in  this  book. 

But  raw  productivity  means  a program  that  formerly  took  three  of 
you  a week  to  write  now  takes  one  of  you  a day  or  two.  This 
touches  several  levelsof  economics.  You're  happy  because  you  get 
the  rush  of  power  that  comes  from  building  something,  your  client 
(or  boss)  is  happy  because  products  are  produced  faster  and  with 
fewer  people,  and  the  customers  are  happy  because  they  get 
products  more  cheaply.  The  only  way  to  get  massive  i ncreases  i n 
productivity  isto  leverage  off  other  people's  code.  That  is,  to  use 
libraries. 

A library  issimply  a bunch  of  codethat  someone  else  has  written 
and  packaged  together.  Often,  the  most  minimal  package  is  a file 
with  an  extension  likeliband  one  or  more  header  files  to  tel  I your 
compi  ler  what's  i n the  I i brary.  The  I i nker  knows  how  to  search 
through  the  library  file  and  extract  the  appropriate  compi  led  code. 
Butthat'sonly  oneway  to  deliver  a library.  On  platforms  that  span 
many  architectures,  such  as  Linux/  Unix,  often  the  only  sensible 
way  to  deliver  a library  is  with  source  code,  so  it  can  be 
reconfigured  and  recompiled  on  the  new  target. 
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Thus,  librariesareprobably  the  most  important  way  to  improve 
productivity,  and  one  of  the  primary  design  goaisof  C++isto 
make  i i brary  use  easier.  This  i mpi  i es  that  there's  someth!  ng  hard 
about  using  libraries  in  C.  Understanding  this  factor  will  giveyou  a 
first  insight  into  thedesign  of  C++,  and  thus  insight  into  how  to  use 
it. 


A tiny  C-like  library 

A library  usually  starts  out  as  a collection  of  functions,  but  if  you 
have  used  third-party  C libraries  you  know  there's  usually  more  to 
it  than  that  because  there's  more  to  life  than  behavior,  actions,  and 
functions.  There  are  also  characteristics  (blue,  pounds,  texture, 
luminance),  which  are  represented  by  data.  And  when  you  start  to 
deal  with  a set  of  characteristics  in  C,  it  is  very  convenient  to  clump 
them  together  into  a struct  especially  if  you  want  to  represent 
more  than  one  similar  thing  in  your  problem  space.  Then  you  can 
make  a variable  of  this  structfor  each  thing. 

Thus,  mostC  libraries  have  a set  of  struct  and  a set  of  functions 
that  act  on  those  struct.  As  an  example  of  what  such  a system 
looks  like,  consider  a programming  tool  that  acts  I ike  an  array,  but 
whose  sizecan  be  established  at  runtime,  when  it  iscreated.  I'll  call 
it  a CStasK  Although  it'swritten  in  C-I-+,  it  has  the  style  of  what 
you'd  write  in  C: 


//:  C04:CLib.h 

//  Header  file  for  a C-like  library 

//  An  array-like  entity  created  at  runtime 

typedef  struct  CStashTag  { 

int  size;  //  Size  of  each  space 

int  quantity;  //  Number  of  storage  spaces 
int  next;  //  Next  empty  space 

//  Dynamically  allocated  array  of  bytes: 
unsigned  char*  storage; 

} CStash; 
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void  initialize (CStash*  s,  int  size); 
void  cleanup (CStash*  s); 

int  add(CStash*  s,  const  void*  element); 
void*  fetch (CStash*  s,  int  index); 
int  count (CStash*  s); 

void  inflate  (CStash*  s,  int  increase); 

///:- 

A tag  name  I ikeCStashTagis  generally  use(d  for  a struct! n case 
you  need  to  reference  the  struct!  nside  itself.  For  example,  when 
creating  a linked  list  (each  element  in  your  list  contains  a pointer  to 
the  next  element),  you  need  a pointer  to  the  next  structvari able,  so 
you  need  a way  to  identify  the  type  of  that  pointer  within  the  struct 
body.  Also,  you'll  almost  universally  see  the  typedef  as  shown 
above  for  every  struct!  n a C 1 1 brary . Thi  s I s done  so  you  can  treat 
thestructas  if  it  were  a new  type  and  define  variables  of  that  struct 
like  this: 

CStash  A,  B,  C; 

Thestoragepointer  is  an  unsigned  charfAn  unsigned  chaiisthe 

smallest  pieceof  storage  a C compiler  supports,  although  on  some 
machines  it  can  be  the  same  size  as  the  largest.  It's  implementation 
dependent,  but  is  often  one  byte  long.  You  might  think  that  because 
theCStash  is  designed  to  hold  any  type  of  variable,  a void*  would 
be  more  appropriate  here.  H owever,  the  purpose  is  not  to  treat  this 
storage  as  a block  of  some  unknown  type,  but  rather  as  a block  of 
contiguous  bytes. 

The  source  codefor  the  implementation  file(which  you  may  not 
get  if  you  buy  a library  commercially -you  might  get  only  a 
compiled  obj  or  lib  or  dll,  etc.)  looks  likethis: 

//:  C04:CLib.cpp  {0} 

//  Implementation  of  example  C-like  library 
//  Declare  structure  and  functions: 

#include  "CLib.h" 

#include  <iostream> 

#include  <cassert> 
using  namespace  std; 
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//  Quantity  of  elements  to  add 
//  when  increasing  storage: 
const  int  increment  = 100; 

void  initialize (CStash*  s,  int  sz)  { 
s->size  = sz; 
s->quantity  = 0; 
s->storage  = 0; 
s->next  = 0; 


int  add (CStash*  s,  const  void*  element)  { 

if(s->next  >=  s->quantity)  //Enough  space  left? 

inflate (s,  increment); 

//  Copy  element  into  storage, 

//  starting  at  next  empty  space: 
int  startBytes  = s->next  * s->size; 
unsigned  char*  e = (unsigned  char* ) element ; 
for(int  i = 0;  i < s->size;  i++) 
s->storage [ startBytes  + i]  = e[i]; 
s->next++ ; 

return ( s->next  - 1);  //  Index  number 


void*  fetch (CStash*  s,  int  index)  { 

//  Check  index  boundaries: 
assert (0  <=  index) ; 
if (index  >=  s->next) 

return  0;  //  To  indicate  the  end 
//  Produce  pointer  to  desired  element: 
return  &( s->storage [ index  * s->size]); 

} 

int  count (CStash*  s)  { 

return  s->next;  //  Elements  in  CStash 

} 

void  inflate (CStash*  s,  int  increase)  { 
assert (increase  > 0); 

int  newQuantity  = s->quantity  + increase; 
int  newBytes  = newQuantity  * s->size; 
int  oldBytes  = s->quantity  * s->size; 
unsigned  char*  b = new  unsigned  char [newBytes ] ; 
for (int  i = 0;  i < oldBytes;  i++) 

b[i]  = s->storage [ i ] ; //  Copy  old  to  new 
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delete  [] (s->storage) ; //  Old  storage 
s->storage  = b;  //  Point  to  new  memory 
s->quantity  = newQuantity; 


void  cleanup (CStash*  s)  { 
if  (s->storage  !=  0)  { 

cout  <<  "freeing  storage"  <<  endl; 
delete  [ ] s->storage; 

} 

} ///:- 

initialize(  )performsthe  necessary  setup  for  struct  CStashby 
setti  ng  the  i nternal  variables  to  appropriate  values.  Initially,  the 
storagepoi nter  is  set  to  zero  - no  initial  storage  is  allocated. 

Theadd(  )function  inserts  an  elennent  into  the  CStash  at  the  next 
available  location.  First,  it  checksto  see  ifthere  is  any  available 
spaceleft.  If  not,  it  expands  the  storage  using  theinflate(  Kunction, 
described  later. 

Because  the  compi  I er  doesn't  know  the  specif  i c type  of  the  vari  abl  e 
being  stored  (all  the  function  gets  is  a void*),  you  can'tjustdoan 
assignment,  which  would  certainly  bethe  convenient  thing. 

I nstead,  you  must  copy  the  variable  byte-by-byte.  The  most 
straightforward  way  to  perform  the  copying  iswith  array  indexing. 
Typically,  there  are  already  data  bytes  in  storage  and  this  is 
indicated  by  the  value  of  next  To  start  with  the  right  byte  offset, 
next  is  multiplied  by  the  size  of  each  element  (in  bytes)  to  produce 
startBytesThen  the  argument  elementis  cast  to  an  unsigned  chatf* 
so  that  it  can  be  addressed  byte-by-byte  and  copied  into  the 
availablestoragespace.  next  is  incremented  so  that  it  indicates  the 
next  aval  I able  piece  of  storage,  and  the  "index  number"  where  the 
value  was  stored  so  that  value  can  be  retrieved  using  this  index 
number  with  fetch( ) 

fetch(  )checks  to  see  that  the  index  isn't  out  of  bounds  and  then 
returnstheaddress  of  the  desired  variable,  calculated  using  the 
i ndexargu  ment.  Si  nee  i ndex  i nd  i cates  the  nu  mber  of  el  ements  to 
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offset  i nto  the  C StasK  it  must  be  multi  pi  ied  by  the  number  of  bytes 
occupied  by  each  piece  to  produce  the  numerical  offset  in  bytes. 
When  this  offset  is  used  to  index  into  storageusing  array  indexing, 
you  don't  get  the  address,  but  instead  the  byte  at  the  address.  To 
produce  the  address,  you  must  usetheaddress-of  operator  &. 

count(  )may  look  a bit  strange  at  first  to  a seasoned  C programmer. 
It  seems  I ike  a lot  of  trouble  to  go  through  to  do  something  that 
would  probably  be  a lot  easier  to  do  by  hand.  If  you  have  a struct 
CStash called  intStash  for  example,  it  would  seem  much  more 
straightforward  to  find  out  how  many  elements  it  has  by  saying 
intStash  .next  nstead  of  making  afunction  call  (which  has 
overhead),  such  as  count(&  intStash.)  How  ever,  if  you  wanted  to 
change  the  internal  representation  of  CStash  and  thustheway  the 
count  was  calculated,  thefunction  call  interface  allows  the 
necessary  flexibility.  But  alas,  most  programmers  won't  bother  to 
find  out  about  your  "better"  design  for  the  library.  They'll  look  at 
thestructand  grab  the  nextvalue  directly,  and  possibly  even 
change  nextwithout  your  permission.  If  only  there  were  someway 
for  the  I i brary  desi  gner  to  have  better  control  over  thi  ngs  I i ke  thi  s! 
(Yes,  that's  foreshadowing.) 

Dynamic  storage  allocation 

You  never  know  the  maxi  mum  amount  of  storage  you  might  need 
for  a C Stash,  so  the  memory  poi  nted  to  by  storagei s al  I ocated  from 
the /leap.  The  heap  is  a big  block  of  memory  used  for  allocating 
smaller  pieces  at  runtime.  You  use  the  heap  when  you  don't  know 
thesizeof  the  memory  you'll  need  whileyou'rewriting  a program. 
That  is,  only  at  runtime  will  you  find  out  that  you  need  space  to 
hold  200Airplanevariables  instead  of  20.  In  Standard  C,  dynamic- 
memory  allocation  functions  include  malloc(  )calloc(  )realloc( ) 
and  free( ) Instead  of  library  calls,  however,  C-H-hasa  more 
sophi sti cated  (al  belt  si  mpl er  to  use)  approach  to  dy nami c memory 
that  i s i ntegrated  i nto  the  I anguage  vi a the  keywords  new  and 
delete 
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Theinflate(  Jfunction  uses  new  to  get  a bigger  chunk  of  space  for 
theCStasK  In  this  situation,  we  will  only  expand  mennory  and  not 
shrink  it,  and  theassert(  )will  guarantee  that  a negative  number  is 
not  passed  to  inflate(  )astheincreasevalue.  The  new  number  of 
elements  that  can  beheld  (after  inflate(  Completes)  is  calculated  as 
newQuantity  and  this  is  multiplied  by  the  number  of  bytes  per 
el  ement  to  p rod  u ce  n ew  B y tes  w h i ch  w i 1 1 be  th  e n u m ber  of  bytes  i n 
the  al  location.  So  that  we  know  how  many  bytes  to  copy  over  from 
the  old  location,  oldBytesis  calculated  using  the  old  quantity 

The  actual  storage  allocation  occurs  in  the  nen/-e)cpress/on,  which  is 
the  expression  involving  the  new  keyword: 

new  unsigned  char [newBytes ] ; 

The  general  form  of  thenew-expression  is: 

new  Type; 

in  which  Typedescribes  the  type  of  variableyou  want  allocated  on 
the  heap.  I n this  case,  we  want  an  array  of  unsigned  chaithat  is 
newByteslong,  sothat  is  what  appears  as  the  Type  You  can  also 
al  I ocate  someth!  ng  as  si  mpl  e as  an  i nt  by  say i ng: 

new  int ; 

and  although  this  is  rarely  done,  you  can  see  that  the  form  is 
consistent. 

A new-expression  returns  a pointer  to  an  object  of  the  exact  type 
that  you  asked  for.  So  if  you  say  new  Type  you  get  back  a poi  nter 
to  a Type  If  you  say  new  int  you  get  back  a poi  nter  to  an  int  If 
you  want  a new  unsigned  chaiarray,  you  get  back  a pointer  to  the 
firstelementof  that  array.  The  compiler  will  ensure  that  you  assign 
the  return  value  of  thenew-expression  to  a pointer  of  the  correct 
type. 
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Of  course,  any  time  you  request  memory  it's  possible  for  the 
request  to  fail,  ifthereisnomorememory.  Asyou  will  learn,  C++ 
has  mechanismsthat  come  into  play  if  the  memory-allocation 
operation  is  unsuccessful. 

Once  the  new  storage  is  allocated,  the  data  in  the  old  storage  must 
be  copied  to  the  new  storage;  this  is  again  accomplished  with  array 
indexing,  copying  one  byte  at  a ti me  i n a loop.  After  the  data  is 
copied,  the  old  storage  must  be  released  so  that  it  can  be  used  by 
other  parts  of  the  program  if  they  need  new  storage.  The  delete 
keyword  isthecomplementof  new,  and  must  be  applied  to  release 
any  storage  that  is  allocated  with  new  (if  you  forget  to  use  delete 
that  storage  remains  unavail  able,  and  if  this  so-called  memory  leak 
happens  enough,  you'll  run  out  of  memory).  In  addition,  there's  a 
special  syntax  when  you're  deleting  an  array.  It's  as  if  you  must 
remi  nd  the  compi  I er  that  this  poi nter  i s not  just  poi nti ng  to  one 
object,  but  to  an  array  of  objects:  you  put  a set  of  empty  square 
brackets  i n front  of  the  poi  nter  to  be  del  eted : 

delete  []myArray; 

Once  the  old  storage  has  been  deleted,  the  poi  nter  to  the  new 
storage  can  be  assigned  tothestoragepointer,  the  quantity  is 
adjusted,  and  inflate(  )has  completed  itsjob. 

Note  that  the  heap  manager  isfairly  primitive.  Itgivesyou  chunks 
of  memory  and  takes  them  back  when  you  deletethem.  There's  no 
inherent  facility  for  heap  compaction,  which  compresses  the  heap  to 
provide  bigger  free  chunks.  If  a program  allocates  and  frees  heap 
storagefor  a while,  you  can  end  up  with  a fragmented  heap  that  has 
lots  of  memory  free,  but  without  any  pieces  that  are  big  enough  to 
allocate  the  size  you 're  looking  for  at  the  moment.  A heap 
compactor  compi  i cates  a program  because  it  moves  memory 
chunks  around,  so  your  pointers  won't  retain  their  proper  values. 
Some  operati ng  environments  have  heap  compaction  built  in,  but 
they  require  you  to  use  special  memory  handles  (which  can  be 
temporari  ly  converted  to  poi  nters,  after  locki  ng  the  memory  so  the 
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heap  compactor  can't  move  it)  instead  of  pointers.  You  can  also 
build  your  own  heap-compaction  scheme,  but  this  is  not  a task  to 
be  undertaken  lightly. 

When  you  create  a variable  on  the  stack  at  compi  le-ti  me,  the 
storage  for  that  variable  is  automatically  created  and  freed  by  the 
compiler.  The  compiler  knows  exactly  how  much  storage  is  needed, 
and  it  knows  the  lifetime  of  the  variables  because  of  scoping.  With 
dynamic  memory  allocation,  however,  the  compiler  doesn't  know 
how  much  storage  you're  goi  ng  to  need,  ancMt  doesn't  know  the 
I ifeti  me  of  that  storage.  That  i s,  the  storage  doesn't  get  cl eaned  u p 
automatically.  Therefore,  you're  responsible  for  releasing  the 
storage  using  delete  which  tel  Is  the  heap  manager  that  storage  can 
be  used  by  the  next  call  to  new.  The  logical  placefor  this  to  happen 
in  thelibrary  is  in  thecleanup(  Kunction  because  that  is  where  all 
the  closing-up  housekeeping  is  done. 

T 0 test  the  1 1 brary,  two  C Stashes  are  created . The  f I rst  hoi ds  i nfe 
and  the  second  holds  arrays  of  80  chars: 

//:  C04 : CLibTest . cpp 
//{L}  CLib 

//  Test  the  C-like  library 
#include  "CLib.h" 

#include  <fstream> 

#include  <iostream> 

#include  <string> 

#include  <cassert> 
using  namespace  std; 

int  main  ( ) { 

//  Define  variables  at  the  beginning 
//  of  the  block,  as  in  C: 

CStash  intStash,  stringStash; 

int  i ; 

char*  cp; 

ifstream  in; 

string  line; 

const  int  bufsize  = 80; 

//  Now  remember  to  initialize  the  variables: 
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initialize (&intStash,  sizeof (int) ) ; 
for(i  = 0;  i < 100;  i++) 

add (&intStash,  &i)  ; 
for(i  = 0;  i < count  (&intStash) ; i++) 

cout  <<  "fetch (&intStash,  " <<  i <<  ")  = " 

<<  * (int*) fetch (&intStash,  i) 

<<  endl; 

//  Holds  80-character  strings: 

initialize (&stringStash,  sizeof (char) *bufsize) ; 
in . open ( "CLibTest . cpp" ) ; 
assert (in) ; 

while (getline (in,  line)) 

add (&stringStash,  line . c_str ( ) ) ; 
i = 0; 

while ( (cp  = (char* ) fetch ( &stringStash, i++) )! =0 ) 
cout  <<  "fetch (&stringStash,  " <<  i <<  ")  = " 

<<  cp  <<  endl; 
cleanup (&intStash) ; 
cleanup (&stringStash)  ; 

} ///:- 

Following  the  form  required  by  C,  all  the  variables  are  created  at 
the  beginning  of  thescopeof  main( ) Of  course,  you  must 
remember  to  I niti  alize  the  C Stash  variables  later  in  the  block  by 
calling  initialize(  )Oneof  the  problems  with  C libraries  is  that  you 
must  careful  ly  convey  to  the  user  the  I mportance  of  the 
initialization  and  cleanup  functions.  If  these  functions  aren't  cal  led, 
therewill  bea  lot  of  trouble.  Unfortunately,  the  user  doesn't  always 
wonder  if  initialization  and  cleanup  are  mandatory.  They  know 
what  they  want  to  accompi  ish,  and  they're  not  as  concerned  about 
you  jumping  up  and  down  saying,  "Hey,  wait,  you  haveto  do  this 
first!"  Some  users  have  even  been  known  to  initializethe  elements 
of  a structure  themselves.  There's  certainly  no  mechanism  in  C to 
prevent  it  (more foreshadowing). 

The  intStash  is  filled  up  with  integers,  and  the  stringStashis  filled 
with  character  arrays.  These  character  arrays  are  produced  by 
open i ng  the  sou rce  code  f i 1 e,  C L i bT estcpp  and  read i ng  the  1 i nes 
from  it  into  a string  cal  led  line  and  then  producing  a pointer  to  the 
character  representation  of  lineusing  the  member  function  c_str( ) 
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After  each  Stash  is  loaded,  it  is  displayed.  TheintStashis  printed 
using  a for  loop,  which  usescount(  )to  establish  its  limit.  The 
stringStashis  printed  with  a while  which  breaks  out  when  fetch( ) 
returns  zero  to  indicate  it  is  out  of  bounds. 

You'll  also  notice  an  additional  cast  in 

I cp  = (char*) fetch (&stringStash, i++) 

This  is  dueto  the  stricter  type  checking  in  C++,  which  does  not 
allow  you  to  simply  assign  a void*to  any  other  type(C  allows 
this). 

Bad  guesses 

There  is  one  more  important  issue  you  should  understand  before 
we  I ook  at  the  general  probi  ems  i n creati  ng  a C I i brary . N ote  that 
theCLib.h  header  file  mtyst  be  included  in  any  file  that  refers  to 
C Stash  because  the  compiler  can't  even  guess  at  what  that 
structure  looks  like.  However,  it  can  guess  at  what  a function  looks 
I i ke;  this  sounds  I ike  a feature  but  it  turns  out  to  be  a major  C 
pitfall. 

Although  you  should  always  declare  functions  by  including  a 
header  file,  function  declarations  aren't  essential  in  C.  It's  possible 
in  C (but  not  in  C++)  to  call  a function  that  you  haven't  declared.  A 
good  compilerwill  warn  you  that  you  probably  ought  to  declare  a 
function  first,  but  it  isn't  enforced  by  the  C language  standard.  This 
is  a dangerous  practice,  because  theC  compiler  can  assumethata 
function  that  you  call  with  an  int argument  has  an  argument  list 
containing  int;  even  if  it  may  actually  contain  afloat  This  can 
produce  bugs  that  are  very  difficuittofind,  as  you  will  see. 

Each  separatee  implementation  file  (with  an  extension  of  .c)  is  a 
translation  unit.  That  is,  the  compiler  is  run  separately  on  each 
translation  unit,  and  when  it  is  running  it  isawareof  only  that  unit. 
Thus,  any  information  you  provide  by  including  header  files  is 
qu  ite  i mportant  because  it  determi  nes  the  compi  I er's 
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understanding  of  the  rest  of  your  program.  Declarations  in  header 
files  are  particularly  important,  because  everywhere  the  header  is 
included,  the  compiler  will  know  exactly  what  to  do.  If,  for 
example,  you  have  a declaration  in  a header  filethat  says  void 
func(fl  oat)  the  compiler  knows  that  if  you  call  that  function  with 
an  integer  argument,  it  should  convert  the  intto  a floatas  it  passes 
the  argument  (this  is  cal  led  promotion).  Without  the  declaration,  the 
C compiler  would  simply  assume  that  a function  func(int)existed, 
it  wouldn't  do  the  promotion,  and  the  wrong  data  would  quietly  be 
passed  intofunc( ) 

For  each  translation  unit,  the  compiler  creates  an  object  file,  with  an 
extension  of  .o  or  .obj  or  something  similar.  These  object  files,  along 
with  the  necessary  start-up  code,  must  be  collected  by  the  linker 
into  the  executable  program.  During  linking,  all  the  external 
references  must  be  resolved.  For  example,  in  CLibTestcpp 
functions  such  asinitialize(  )andfetch(  )are  declared  (that  is,  the 
compiler  istold  what  they  look  like)  and  used,  but  not  defined. 
They  are  defined  elsewhere,  in  CLib.cpp  Thus,  the  calls  in 
C Li b.cppare external  references.  The  linker  must,  when  it  puts  all 
the  object  files  together,  taketheunresolved  external  references  and 
find  the  addresses  they  actual  ly  refer  to.  Those  addresses  are  put 
i nto  the  executable  program  to  replace  the  external  references. 

I t's  i mportant  to  real  i ze  that  i n C , the  external  references  that  the 
linker  searches  for  are  simply  function  names,  generally  with  an 
underscore  in  front  of  them.  So  all  the  linker  has  to  do  is  match  up 
thefunction  name  where  it  iscalled  and  thefunction  body  in  the 
object  file,  and  it'sdone.  If  you  accidentally  madeacall  that  the 
compiler  interpreted  asfunc(int)and  there's  a function  body  for 
func(float)in  someotherobjectfile,  the  I inker  will  see_funcin  one 
pl  ace  and  _f  unci  n another,  and  it  will  think  everything's  OK.  The 
func(  )at  the  cal  ling  location  will  push  an  intonto  the  stack,  and 
thefunc(  )function  body  will  expect  a floatto  be  on  the  stack.  If  the 
function  only  reads  the  value  and  doesn't  write  to  it,  it  won't  blow 
up  the  stack.  In  fact,  the  float  value  it  reads  off  the  stack  might  even 
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make  some  kind  of  sense.  That's  worse  because  it's  harder  to  find 
the  bug. 


What's  wrong? 

We  are  remarkably  adaptable,  even  in  situations  in  which  perhaps 
we  shouldn  't  adapt.  The  sty  I e of  the  C Stash  I i brary  has  been  a stapi  e 
forC  programmers,  but  if  you  look  at  it  for  a while,  you  might 
notice  that  it's  rather . . . awkward.  When  you  use  it,  you  have  to 
passtheaddress  of  the  structure  to  every  single  function  in  the 
library.  When  reading  the  code,  the  mechanism  of  the  library  gets 
mixed  with  the  meaning  of  the  function  calls,  which  is  confusing 
when  you're  trying  to  understand  what's  going  on. 

One  of  the  biggest  obstacles,  however,  to  using  libraries  in  C is  the 
problem  of  name  clashes.  C has  a single  name  space  for  functions; 
that  is,  when  the  linker  looks  for  a function  name,  it  looks  in  a 
single  master  list.  In  addition,  when  the  compiler  isworking  on  a 
translation  unit,  it  can  work  only  with  a single  function  with  a 
given  name. 

Now  suppose  you  decideto  buy  two  libraries  from  two  different 
vendors,  and  each  library  has  a structure  that  must  be  initialized 
and  cleaned  up.  Both  vendors  decided  thatinitialize(  )and 
cleanup(  )aregood  names.  If  you  includeboth  their  header  filesin 
a single  translation  unit,  what  does  the  C compiler  do?  Fortunately, 
C gives  you  an  error,  telling  you  there's  a type  mismatch  in  the  two 
different  argument  lists  of  the  declared  functions.  But  even  if  you 
don't  include  them  in  the  same  translation  unit,  the  linker  will  still 
have  problems.  A good  linker  will  detect  that  there's  a name  clash, 
but  some  I inkers  take  the  first  function  name  they  find,  by 
searchi  ng  through  the  I i st  of  object  fi  I es  i n the  order  you  gi  ve  them 
in  thelink  list.  (Thiscan  even  be  thought  of  as  a feature  because  it 
allowsyou  to  replacea  library  function  with  your  own  version.) 
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In  either  event,  you  can't  use  two  C libraries  that  contain  a function 
with  the  identical  name.  To  solve  this  problem,  C library  vendors 
will  often  prepend  a sequence  of  unique  characters  to  the  beginning 
of  all  their  function  names.  So  initialize(  )and  cleanup(  )might 
becomeCStash_initialize(  ^nd  CStash_cleanup(.)This  isa 
logical  thing  to  do  because  it  "decorates"  thenameof  thestructthe 
function  works  on  with  thenameof  thefuncti  on. 

Now  it's  time  to  take  the  first  step  toward  creating  classesin  C++. 
Variablenamesinsideastructdonotclash  with  global  variable 
names.  So  why  not  take  advantage  of  this  for  function  names,  when 
those  functions  operate  on  a particular  struck  That  is,  why  not 
make  fu ncti  ons  members  of  struck? 


The  basic  object 

Step  one  is  exactly  that.  C++ functions  can  be  placed  inside  strucfe 
as  "member  functions."  Here's  what  it  looks  I ike  after  converting 
the  C versi  on  of  C Stash  to  the  C ++  Stash: 

//:  C04:CppLib.h 

//  C-like  library  converted  to  Ct+ 
struct  Stash  { 

int  size;  //  Size  of  each  space 

int  quantity;  //  Number  of  storage  spaces 
int  next;  //  Next  empty  space 

//  Dynamically  allocated  array  of  bytes: 
unsigned  char*  storage; 

//  Functions ! 

void  initialize  (int  size); 
void  cleanup  ( ) ; 
int  add(const  void*  element); 
void*  fetch (int  index); 
int  count  ( ) ; 

void  inflate  (int  increase); 

};  ///:- 

First,  notice  there  is  no  typedef.  Instead  of  requiring  you  to  create  a 
typedef,  theC++compiler  turns  the  name  of  the  structure  into  a 
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new  type  namefor  the  program  (just  as  int  char,  floatand  double 
are  type  names). 

A 1 1 the  data  members  are  exactly  the  same  as  before,  but  now  the 
functions  are  insidethe  body  of  the  struct  In  addition,  notice  that 
the  f i rst  argu  ment  from  the  C versi  on  of  the  I i brary  has  been 
removed . I n C ++,  i nstead  of  forci  ng  you  to  pass  the  add  ress  of  the 
structu  re  as  the  f i rst  argu  ment  to  al  I the  f u ncti  ons  that  operate  on 
that  structure,  the  compiler  secretly  does  this  for  you.  Now  the  only 
arguments  for  the  functions  are  concerned  with  what  the  function 
does,  not  the  mechani  sm  of  the  fu  ncti  on's  operati  on. 

It's  important  to  realize  that  the  function  code  is  effectively  the 
same  as  it  was  with  theC  version  of  the  library.  The  number  of 
arguments  is  the  same  (even  though  you  don't  see  the  structu  re 
address  being  passed  in,  it's  still  there),  and  there's  only  one 
function  body  for  each  function.  That  is,  just  because  you  say 

Stash  A,  B,  C; 

doesn't  mean  you  get  a different  add(  )function  for  each  variable. 

So  the  code  that's  generated  is  almost  identical  to  what  you  would 
have  written  for  theC  version  of  the  I i brary . Interestingly  enough, 
this  includes  the  "name  decoration"  you  probably  would  have 
doneto  p rod uceStash_initialize(,)Stash_ cleanup (,)and  so  on. 
When  the  function  name  is  inside  the  struct  the  compiler 
effectively  does  the  same  thing.  Therefore,  lnltlallze(  )nsidethe 
structure  Stash  will  not  collide  with  afunction  named  lnltiallze( ) 
inside  any  other  structure,  or  even  a global  function  named 
lnltialize( ) Most  of  the  time  you  don't  haveto  worry  about  the 
function  name  decoration  - you  use  the  undecorated  name.  But 
sometimes  you  do  need  to  beableto  specify  that  this  initialize( ) 
belongs  to  the  structStash,  and  not  to  any  other  struct  I n 
particular,  when  you're  definingthefunction  you  need  to  fully 
specify  which  one  it  is.  To  accomplish  thisfull  specification,  C++ 
has  an  operator  (::)  called  the  scope  resolution  operator  (named  so 
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because  names  can  now  be  i n different  scopes:  at  global  scope  or 
within  the  scope  of  a struct-  For  example,  if  you  want  to  specify 

initialize(  )which  belongs  to  Stash,  you  say  Stash::initialize(int 
size)  You  can  see  how  the  scope  resolution  operator  is  used  in  the 
function  definitions: 

//:  C04:CppLib.cpp  {0} 

//  C library  converted  to  C++ 

//  Declare  structure  and  functions: 

#include  "CppLib.h" 

#include  <iostreain> 

#include  <cassert> 
using  namespace  std; 

//  Quantity  of  elements  to  add 
//  when  increasing  storage: 
const  int  increment  = 100; 

void  Stash: : initialize (int  sz)  { 
size  = sz; 
quantity  = 0; 
storage  = 0; 
next  = 0; 


int  Stash :: add (const  void*  element)  { 

if (next  >=  quantity)  //  Enough  space  left? 

inflate (increment) ; 

//  Copy  element  into  storage, 

//  starting  at  next  empty  space: 
int  startBytes  = next  * size; 
unsigned  char*  e = (unsigned  char* ) element ; 
for(int  i = 0;  i < size;  i++) 
storage [ startBytes  + i]  = e[i]; 
next++ ; 

return  (next  - 1);  //  Index  number 

} 

void*  Stash :: fetch ( int  index)  { 

//  Check  index  boundaries: 
assert (0  <=  index) ; 
if (index  >=  next) 

return  0;  //  To  indicate  the  end 
//  Produce  pointer  to  desired  element: 
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return  &( storage [ index  * size]); 

} 

int  Stash :: count  ( ) { 

return  next;  //  Number  of  elements  in  CStash 

} 

void  Stash :: inf late  ( int  increase)  { 
assert (increase  > 0); 

int  newQuantity  = quantity  + increase; 
int  newBytes  = newQuantity  * size; 
int  oldBytes  = quantity  * size; 

unsigned  char*  b = new  unsigned  char [newBytes ] ; 
for  (int  i = 0;  i < oldBytes;  i++) 

b[i]  = storage [i];  //  Copy  old  to  new 
delete  [] storage;  //  Old  storage 
storage  = b;  //  Point  to  new  memory 
quantity  = newQuantity; 


void  Stash :: cleanup ( ) { 

if (storage  ! = 0 ) { 

cout  <<  "freeing  storage"  <<  endl; 
delete  [] storage; 

} 

} ///:- 

There  are  several  other  things  that  are  (different  between  C an6 
C++.  First,  the  (declarations  in  the  header  files  are  required  by  the 
compiler.  In  C++you  cannot  call  a function  without  declaring  it 
first.  The  compiler  will  issue  an  error  message  otherwise.  This  is  an 
important  way  to  ensure  that  function  cal  Is  are  consistent  between 
the  point  where  they  are  called  and  the  point  where  they  are 
defined.  By  forcing  you  to  declarethefunction  before  you  call  it, 
theC++compiler  virtually  ensures  that  you  will  perform  this 
declaration  by  including  the  header  file.  If  you  also  includethe 
same  header  f i I e i n the  place  w here  the  fu  ncti  ons  are  defi  ned,  then 
the  compiler  checks  to  makesurethatthedeclaration  in  the  header 
and  thefunction  definition  match  up.  This  means  that  the  header 
file  becomes  a validated  repository  for  function  declarations  and 
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ensures  that  functions  are  used  consistently  throughout  all 
translation  units  in  the  project. 

Of  course,  global  functions  can  still  be  declared  by  hand  every 
place  where  they  aredefined  and  used.  (This  is  so  tedious  that  it 
becomes  very  unlikely.)  However,  structures  must  always  be 
declared  before  they  aredefined  or  used,  and  the  most  convenient 
place  to  put  a structure  definition  is  in  a header  file,  except  for 
those  you  intentionally  hide  in  a file. 

You  can  see  that  all  the  member  functions  look  al  most  the  same  as 
when  they  wereC  functions,  except  for  the  scope  resolution  and 
the  fact  that  the  first  argument  from  theC  version  of  the  library  is 
no  longer  explicit.  It's  still  there,  of  course,  because  the  function  has 
to  be  able  to  work  on  a particular  structvariable.  But  notice,  inside 
the  member  function,  that  the  member  selection  is  also  gone!  Thus, 
instead  of  saying  s->size  = sz,you  say  size  = sz;and  eliminate  the 
tediouss->,  which  didn't  really  add  anything  to  the  meaning  of 
what  you  were  doing  anyway.  The  C++ compiler  is  apparently 
doing  thisfor  you.  Indeed,  it  is  taking  the  "secret"  first  argument 
(theaddressof  the  structure  that  we  were  previously  passing  in  by 
hand)  and  applyi  ng  the  member  selector  whenever  you  refer  to  one 
of  the  data  members  of  a struct  This  means  that  whenever  you  are 
inside  the  member  function  of  another  struct  you  can  refer  to  any 
member  (including  another  member  function)  by  simply  giving  its 
name.  The  compiler  will  search  through  the  local  structure's  names 
before  looking  for  a global  version  of  that  name.  You'll  find  that 
this  feature  means  that  not  only  is  your  code  easier  to  write,  it's  a 
lot  easier  to  read. 

But  what  if,  for  some  reason,  you  want  to  be  able  to  get  your  hands 
on  theaddressof  the  structure?  In  the  C version  of  the  library  it 
was  easy  because  each  function's  fi  rst  argument  was  a C Stash* 
called  s.  In  C++,  things  are  even  more  consistent.  There's  a special 
keyword,  called  this  which  produces  the  address  of  the  struct  It's 
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the  equivalent  of  the 's'  in  theC  version  of  the  library.  So  we  can 
revert  to  theC  style  of  things  by  saying 

this->size  = Size; 

The  code  generated  by  the  compi  ler  is  exactly  the  same,  so  you 
don't  need  to  usethisin  such  a fashion;  occasionally,  you'll  see 
code  where  people  expl  icitly  usethis->everywhere  but  it  doesn't 
add  anything  to  the  meaning  of  the  code  and  often  indicates  an 
inexperienced  programmer.  Usually,  you  don't  use  this  often,  but 
when  you  need  it,  it's  there  (some  of  the  examples  later  in  the  book 
will  usethis). 

There's  one  last  item  to  mention.  In  C,  you  could  assign  a void*to 
any  other  poi  nter  I i ke  thi  s: 

int  i = 10; 

void*  vp  = &i;  //  OK  in  both  C and  C++ 

int*  ip  = vp;  //  Only  acceptable  in  C 

and  there  was  no  complaint  from  the  compi  ler.  But  in  C++,  this 
statement  is  not  allowed.  Why?  Because  C is  not  so  particular  about 
type  information,  so  itallowsyou  to  assign  a pointer  with  an 
unspecified  type  to  a pointer  with  a specified  type.  Not  so  with 
C++.  Type  is  critical  in  C++,  and  the  compi  ler  stamps  its  foot  when 
there  are  any  violations  of  type  information.  This  has  always  been 
important,  but  it  is  especially  important  in  C++ because  you  have 
member  functions  in  struct.  If  you  could  pass  pointers  to  struct 
around  with  impunity  in  C++,  then  you  could  end  up  calling  a 
member  function  for  a structthat  doesn't  even  logically  exist  for 
that  struct  A real  recipefor  disaster.  Therefore,  whileC++allows 
the  assignment  of  any  type  of  poi  nter  to  a void*  (this  was  the 
original  intentof  void*  which  is  required  to  be  large  enough  to 
hold  a pointer  to  any  type),  itwill  nofallow  you  to  assign  avoid 
poi  nter  to  any  other  type  of  poi  nter.  A cast  is  always  required  to  tel  I 
the  reader  and  the  compi  ler  that  you  real  ly  do  want  to  treat  it  as  the 
destination  type. 
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Thisbringsup  an  interesting  issue.  One  of  the  important  goalsfor 
C++ is  to  compile  as  much  existing  C code  as  possible  to  allow  for 
an  easy  transition  to  the  new  language.  However,  this  doesn't  mean 
any  codethatC  allows  will  automatically  be  all  owed  in  C++.  There 
area  number  of  things  the  C compiler  lets  you  getaway  with  that 
are  dangerous  and  error-prone.  (We'll  look  at  them  as  the  book 
progresses.)  The  C -H-  compi  I er  generates  warn!  ngs  and  errors  for 
these  situations.  This  is  often  much  more  of  an  advantage  than  a 
hindrance.  In  fact,  there  are  many  situations  in  which  you  are 
trying  to  run  down  an  error  in  C and  just  can't  find  it,  but  as  soon 
as  you  recompile  the  program  in  C-H-,  the  compiler  points  out  the 
problem!  In  C,  you'll  often  find  that  you  can  get  the  program  to 
compile,  but  then  you  have  to  get  it  to  work.  In  C++,  when  the 
program  compiles  correctly,  it  often  works,  too!  This  is  because  the 
language  is  a lot  stricter  about  type. 

Y ou  can  see  a nu mber  of  new  th i ngs  i n the  way  the  C -H-  versi on  of 
Stash  is  used  in  the  foil  owing  test  program: 

//:  C04 : CppLibTest . cpp 
//{L}  CppLib 
//  Test  of  C++  library 
#include  "CppLib. h" 

#include  ".. /require . h" 

#include  <fstream> 

#include  <iostream> 

#include  <string> 
using  namespace  std; 

int  main  ( ) { 

Stash  intStash; 

int Stash. initialize (sizeof (int) ) ; 
for(int  i = 0;  i < 100;  i++) 
intStash. add (&i) ; 

for  (int  j = 0;  j < intStash . count () ; j++) 

cout  <<  " intStash . fetch ( " <<  j <<  ")  = " 

<<  *( int *) intStash . fetch ( j ) 

<<  endl; 

//  Holds  80-character  strings: 

Stash  stringStash; 
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const  int  bufsize  = 80; 

stringStash. initialize (sizeof (char)  * bufsize); 
if stream  in  ( "CppLibTest . cpp" ) ; 
assure (in,  "CppLibTest . cpp" ) ; 
string  line; 

while (getline (in,  line)) 

stringStash . add ( line . c_str ( ) ) ; 
int  k = 0; 
char*  cp; 

while ( (cp  = (char* ) stringStash . fetch (k++) ) !=  0) 

cout  <<  " stringStash . fetch ( " <<  k <<  ")  = " 

<<  cp  <<  endl; 
int St ash . cleanup ( ) ; 
stringStash . cleanup ( ) ; 

} ///:- 

One  thing  you'll  not!  cels  that  the  variables  are  all  (defined  "on  the 
fly"  (as  introduced  in  the  previous  chapter).  That  is,  they  are 
defined  at  any  point  in  the  scope,  rather  than  being  restricted  - as 
i n C - to  the  begi  nni  ng  of  the  scope. 

ThecodeisquitesimilartoCLibTestxppbut  when  a mennber 
function  is  cal  led,  the  cal  I occurs  using  the  mennber  selection 
operator  preceded  by  the  name  of  the  variable.  This  is  a 
convenient  syntax  because  it  mimics  the  selection  of  a data  member 
of  the  structure.  The  difference  is  that  this  is  a function  member,  so 
it  has  an  argument  list. 

Of  course,  the  cal  I that  the  compiler  actually  generates  looks  much 
more  I ike  the  original  C library  function.  Thus,  considering  name 
decoration  and  the  passing  of  thist  the  C++ function  call 

intStash.initialize(sizeof(int),  100)Bcomes something  like 
Stash_initialize(&intStash,  sizeof(int),  KXQyou  ever  wonder 
what's  going  on  underneath  the  covers,  remember  that  the  original 
C++compiler  cfrontfrom  AT&T  produced  C code  as  its  output, 
which  was  then  compiled  by  the  underlying  C compiler.  This 
approach  meant  that  cfrontcou Id  be  quickly  ported  to  any  machine 
that  had  aC  compiler,  and  it  helped  to  rapidly  disseminate  C++ 
compiler  technology.  But  becausethe C++ compiler  had  to  generate 
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C,  you  know  that  there  must  be  some  way  to  represent  C++ syntax 
in  C (some compilers  still  allow  you  to  produceC  code). 

There's  one  other  change  from  ClibTestxpp  which  is  the 
introduction  of  the  require.hheader  file.  Thisisa  header  filethat  I 
created  for  this  book  to  perform  more  sophisticated  error  checking 
than  that  provided  by  assert( ) It  contains  several  functions, 
including  the  one  used  here  called  assure( ), which  is  used  for  files. 
Thisfunction  checksto  see  if  thefile  has  successfully  been  opened, 
and  if  not  it  reports  to  standard  error  that  the  file  could  not  be 
opened  (thus  it  needs  the  name  of  the  file  as  the  second  argument) 
and  exits  the  program.  The  require.hfunctionswill  be  used 
throughout  the  book,  in  particular  to  ensure  that  there  are  the  right 
number  of  command-line  arguments  and  that  files  are  opened 
properly.  The  requi re.hf unctions  replace  repetitive  and  distracting 
error-checking  code,  and  yet  they  provide  essentially  useful  error 
messages.  These  functions  will  be  fully  explained  later  in  the  book. 


What's  an  object? 

Now  that  you've  seen  an  initial  example,  it's  time  to  step  back  and 
take  a I ook  at  some  termi  nol  ogy . The  act  of  bri  ngi  ng  f u ncti  ons 
insidestructures  isthe  root  of  what  C-H- adds  to  C,  and  it 
introduces  a new  way  of  thinking  about  structures:  as  concepts.  In 
C,  a structis  an  agglomeration  of  data,  a way  to  package  data  so 
you  can  treat  it  in  a clump.  But  it's  hard  to  think  about  it  as 
anything  but  a programming  convenience.  The  functions  that 
operate  on  those  structures  are  elsewhere.  However,  with  functions 
in  the  package,  the  structure  becomes  a new  creature,  capable  of 
describing  both  characteristics  (likea  C structdoes)  and  behaviors. 
The  concept  of  an  object,  a free-standi  ng,  bounded  entity  that  can 
remember  and  act,  suggests  itself. 

In  C++,  an  object  isjust  a variable,  and  the  purest  definition  is  "a 
region  of  storage"  (this  is  a more  specific  way  of  saying,  "an  object 
must  have  a unique  identifier,"  which  in  the  case  of  C-H- is  a 
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unique  memory  address).  It's  a place  where  you  can  store  data,  and 
it's  i mpl  i ed  that  there  are  al  so  operati  ons  that  can  be  performed  on 
this  data. 

Unfortunately,  there's  not  complete  consistency  across  languages 
when  it  comes  to  these  terms,  although  they  arefairly  well- 
accepted.  You  will  also  sometimes  encounter  disagreement  about 
what  an  object-oriented  language  is,  although  that  seems  to  be 
reasonably  wel  I sorted  out  by  now.  There  are  languages  that  are 
object- based,  which  means  that  they  haveobjects  liketheC-H- 
structures-with-functionsthatyou'veseen  so  far.  This,  however,  is 
only  part  of  the  picture  when  it  comes  to  an  object-oriented 
language,  and  languages  that  stop  at  packaging  functions  inside 
data  structures  are  object-based,  not  object-oriented. 


Abstract  data  typing 

The  abi  I ity  to  package  data  with  functions  al  lows  you  to  create  a 
new  data  type.  This  is  often  called  en capsu I ation\  An  existing  data 
type  may  have  several  pieces  of  data  packaged  together.  For 
example,  afloathasan  exponent,  a mantissa,  and  a sign  bit.  You 
can  tell  it  to  do  things:  add  to  another  f I oator  to  an  int  and  so  on. 

It  has  characteristics  and  behavior. 

The  definition  of  Stash  creates  a new  data  type.  You  can  add( } 
fetch( ) and  inflate(  )You  create  one  by  saying  Stash  s just  as  you 
create  a float  by  saying  float  f A Stash  also  has  characteristics  and 
behavior.  Even  though  it  acts  I ike  a real,  built-in  datatype,  we  refer 
to  it  as  an  abstract  data  type,  perhaps  because  it  allows  us  to  abstract 
a concept  from  the  problem  space  into  the  solution  space.  I n 
addition,  the  C-H-compi  I er  treats  it  I ike  a new  datatype,  and  if  you 
say  a function  expects  a Stash,  the  compiler  makes  sure  you  pass  a 


^ This  term  can  cause  debate.  Some  people  use  it  as  defi  ned  here;  others  use  it  to 
describe  access  control,  discussed  in  the  following  chapter. 
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Stash  to  that  function.  So  the  same  level  of  type  checking  happens 
with  abstract  data  types  (someti  mes  cal  led  user-defined  types)  as 
with  built-in  types. 

You  can  immediately  see  a difference,  however,  in  the  way  you 
perform  operations  on  objects.  You  say 
object.memberFunction(arglistThis  is  "calling  a member 
function  for  an  object."  But  in  object-oriented  parlance,  this  is  also 
referred  to  as  "sendi  ng  a message  to  an  object."  So  for  a Stash  s the 
statement  s.  add(&i  )"  sends  a message  to  s"  saying,  "add(  )thisto 
yourself."  In  fact,  object-oriented  programming  can  be  summed  up 
in  a single  phrase:  sending  m^sages  to  objects.  Really,  that's  all  you 
do  - create  a bunch  of  objects  and  send  messages  to  them.  The  trick, 
of  course,  is  figuring  out  what  your  objects  and  messages  are,  but 
once  you  accomplish  thisthe  implementation  in  C-H-issurprisingly 
straightforward. 


Object  details 

A question  that  often  comes  up  in  seminars  is,  "How  big  is  an 
object,  and  what  does  it  look  like?"  The  answer  is  "about  what  you 
expect  from  a C struct"  In  fact,  the  code  the  C compiler  produces 
for  aC  struct(with  no  C-h- adornments)  will  usually  look  exactiy 
the  same  as  the  code  produced  by  a C-h- compiler.  This  is 
reassuring  to  those  C programmers  who  depend  on  the  details  of 
size  and  layout  in  their  code,  and  for  some  reason  directly  access 
structure  bytes  instead  of  using  identifiers  (relying  on  a particular 
size  and  layout  for  a structure  is  a nonportable  activity). 

Thesizeof  a struct!  s the  combined  size  of  all  of  its  members. 
Sometimes  when  the  compiler  I ays  out  a struct  it  adds  extra  bytes 
to  makethe  boundaries  comeout  neatly -this  may  increase 
execution  efficiency.  In  Chapter  15,  you'll  see  how  in  some  cases 
"secret"  pointers  are  added  to  the  structure,  but  you  don't  need  to 
worry  about  that  right  now. 
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You  can  determinethesizeof  astructusingthesizeofoperator. 
H ere's  a smal I example: 

//:  C04 : Sizeof . cpp 
//  Sizes  of  structs 
#include  "CLib.h" 

#include  "CppLib.h" 

#include  <iostream> 
using  namespace  std; 

struct  A { 
int  i [ 100 ] ; 

}; 


struct  B { 


void 

}; 

f 0 

r 

void  B 

:f  ( 

) { } 

int  main  ( ) 

{ 

cout 

<< 

"sizeof 

struct  A 

= " <<  sizeof (A) 

<< 

" bytes" 

<<  endl; 

cout 

<< 

"sizeof 

struct  B 

= " <<  sizeof(B) 

<< 

" bytes" 

<<  endl; 

cout 

<< 

"sizeof 

CStash  in 

C = " 

<< 

sizeof (CStash)  << 

" bytes"  <<  endl 

cout 

<< 

"sizeof 

Stash  in 

C++  = " 

<< 

sizeof (Stash)  << 

" bytes"  <<  endl; 

} ///:- 

On  my  machine  (your  results  may  vary)  the  first  print  statement 
produces  200  because  each  int  occupies  two  bytes,  struct  Bis 
something  of  an  anomaly  because  it  is  a structwith  no  data 
members.  In  C,  this  is  illegal,  but  in  C++weneed  the  option  of 
creating  a structw  hose  sole  task  is  to  scope  function  names,  so  it  is 
allowed.  Still,  the  result  produced  by  the  second  print  statement  is 
a somewhat  surprising  nonzero  value.  In  early  versions  of  the 
language,  the  size  was  zero,  but  an  awkward  situation  arises  when 
you  create  such  objects:  They  have  the  same  add  ress  as  the  object 
created  directly  after  them,  and  so  are  not  distinct.  One  of  the 
f u nd amental  ru I es  of  objects  i s that  each  object  must  have  a u ni qu e 
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address,  so  structures  with  no  data  members  will  always  have 
some  minimum  nonzero  size. 

The  last  two  si zeof  statements  show  you  that  the  size  of  the 
structu  re  i n C ++  i s the  same  as  the  si ze  of  the  equ  i val  ent  versi  on  i n 
C.  C++ tries  not  to  add  any  unnecessary  overhead. 


Header  file  etiquette 

When  you  create  a structcontaining  member  functions,  you  are 
creating  a new  datatype.  In  general,  you  want  this  type  to  be  easily 
access!  bleto  yourself  and  others.  In  addition,  you  want  to  separate 
the  interface  (the  declaration)  from  the  implementation  (the 
definition  of  the  member  functions)  so  the  implementation  can  be 
changed  without  forcing  a re-compileof  the  entire  system.  You 
achieve  this  end  by  putting  the  declaration  for  your  new  type  in  a 
header  file. 

When  I first  learned  to  program  in  C,  the  header  file  was  a mystery 
to  me.  Many  C books  don't  seem  to  emphasize  it,  and  the  compiler 
didn't  enforce  function  declarations,  so  it  seemed  optional  most  of 
the  time,  except  when  structures  were  declared.  In  C++theuseof 
header  files  becomes  crystal  clear.  They  are  virtually  mandatory  for 
easy  program  development,  and  you  put  very  specific  information 
in  them:  declarations.  The  header  file  tel  Is  the  compiler  what  is 
availablein  your  library.  You  can  usethe  library  even  if  you  only 
possess  the  header  file  along  with  the  object  file  or  library  file;  you 
don't  need  the  source  code  for  the  cpp  fi  le.  The  header  fi  le  is  where 
the  i nterface  specif i cat! on  i s stored . 

Although  it  is  not  enforced  by  the  compiler,  the  best  approach  to 
bu i I d i ng  I arge  projects  i n C i s to  use  I i brari  es;  col  I ect  associ  ated 
functions  into  the  same  object  module  or  library,  and  usea  header 
fileto  hold  all  the  declarations  for  the  functions.  It  \sderigueur\n 
C ++;  you  cou  I d th  row  any  f u ncti  on  i nto  a C I i brary , but  the  C ++ 
abstract  data  type  determi  nes  the  fu  ncti  ons  that  are  associ  ated  by 
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di  nt  of  thei  r common  access  to  the  data  i n a struct  A ny  member 
function  must  be  declared  in  thestructdeclaration;  you  cannot  put 
itelsewhere.  The  use  of  function  libraries  was  encouraged  inC  and 
institutionalized  in  C++. 

I mportance  of  header  files 

When  using  a function  from  a library,  C allows  you  the  option  of 
ignoring  the  header  file  and  simply  declaring  the  function  by  hand. 
In  the  past,  people  would  sometimes  do  this  to  speed  up  the 
compiler  just  a bit  by  avoiding  the  task  of  opening  and  including 
thefile(this  is  usually  notan  issuewith  modern  compilers).  For 
example,  here's  an  extremely  lazy  declaration  of  the  C function 
printf(  )(from  <stdio.h;::^: 

I printf  (...); 

The  ellipses  specify  a variable  argument  Ust^,  which  says:  printf  ( ) 
has  some  arguments,  each  of  which  has  a type,  but  ignore  that.  Just 
take  whatever  arguments  you  see  and  accept  them.  By  using  this 
kind  of  declaration,  you  suspend  all  error  checking  on  the 
arguments. 

This  practice  can  cause  subtle  problems.  If  you  declare  functions  by 
hand,  in  onefileyou  may  makea  mistake.  Si  nee  the  compiler  sees 
only  your  hand-declaration  in  that  file,  it  may  be  able  to  ad  apt  to 
your  mistake.  The  program  will  then  link  correctly,  but  the  use  of 
thefunction  in  that  onefile  will  befaulty.  Thisisatough  error  to 
find,  and  is  easily  avoided  by  using  a header  file. 

If  you  place  all  yourfunction  declarations  in  a header  file,  and 
includethat  header  everywhere  you  use  the  function  and  where 
you  define  the  function,  you  ensure  a consistent  declaration  across 


2 To  w ri te  a f u ncti  on  d ef i ni ti  on  for  a f u ncti  on  that  takes  a true  vari  abl  e argu ment  I i st, 
you  must  use  varargs,  although  these  should  be  avoided  in  C++.  You  can  find  details 
about  the  use  of  varargs  i n your  C manual . 
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the  whole  system.  You  also  ensure  that  the  declaration  and  the 
definition  match  by  including  theheader  in  the  definition  file. 

If  a struct!  s declared  in  a header  filein  C++, you  must  includethe 
header  file  everywhere  a struct! s used  and  where structmember 
functions  are  defined.  TheC++ compiler  will  give  an  error  message 
if  you  try  to  call  a regular  function,  or  to  cal  I or  define  a member 
function,  without  declaring  itfirst.  By  enforcing  the  proper  use  of 
header  files,  the  language  ensures  consistency  in  libraries,  and 
reduces  bugs  by  forcing  the  same  interface  to  beused  everywhere. 

Theheader  is  a contract  between  you  and  theuser  of  your  library. 
The  contract  descri  bes  your  data  structures,  and  states  the 
arguments  and  return  values  for  the  function  calls.  It  says,  "Here's 
what  my  li  brary  does."  The  user  needs  some  of  this  i nformation  to 
develop  the  application  and  the  compiler  needs  all  of  it  to  generate 
proper  code.  The  user  of  the  structsi  mply  i ncl  udes  the  header  fi  le, 
creates  objects  (i  nstances)  of  that  struct  and  I i nks  i n the  object 
module  or  library  (i.e.:  thecompiled  code). 

The  compiler  enforces  the  contract  by  requiring  you  to  declare  all 
structures  and  functions  before  they  are  used  and,  in  the  case  of 
member  functions,  before  they  aredefined.  Thus,  you'reforced  to 
put  the  declarations  in  theheader  and  to  include  the  header  in  the 
file  where  the  member  functions  are  defined  and  thefilefs)  where 
they  are  used . Because  a si  ngl  e header  fi  I e descri  bi  ng  you r I i brary  i s 
included  throughout  the  system,  the  compiler  can  ensure 
consistency  and  prevent  errors. 

There  are  certai  n issues  that  you  must  be  aware  of  in  order  to 
organize  your  code  properly  and  write  effective  header  fi  les.  The 
first  issue  concerns  what  you  can  put  into  header  files.  The  basic 
rule  is  "only  declarations,"  that  is,  only  information  to  the  compiler 
but  nothi  ng  that  al  I ocates  storage  by  generati  ng  code  or  creati  ng 
vari  abl  es.  Thi  s i s because  the  header  fi  I e wi  1 1 ty  pi  cal  I y be  i ncl  uded 
in  several  translation  units  in  a project,  and  if  storage  for  one 
identifier  is  allocated  in  more  than  oneplace,  the  linker  will  come 
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up  with  a multipledefinition  error  (this \sC++'s  one  definition  ruie. 
You  can  declare  things  as  many  times  as  you  want,  but  there  can  be 
only  one  actual  definition  for  each  thing). 

This  rule  isn't  completely  hard  and  fast.  If  you  define  a variable 
that  is  "file static"  (has  visibility  only  within  afile)  insidea  header 
fi  le,  there  will  be  multi  pie  i nstances  of  that  data  across  the  project, 
but  the  I inker  won't  havea  colli  si  on^.  Basically,  you  don't  want  to 
do  anything  in  the  header  filethat  will  cause  an  ambiguity  at  link 
time. 


The  multiple-declaration  problem 

The  second  header-file  issue  is  this:  when  you  put  a struct 
declaration  in  a header  file,  it  is  possible  for  the  file  to  beincluded 
more  than  once  in  a complicated  program,  lostreams  area  good 
example.  Any  timeastructdoes  1/  O it  may  include  one  of  the 
iostream  headers.  If  the  cpp  file  you  are  working  on  uses  more  than 
one  kind  of  struct(typically  including  a header  file  for  each  one), 
you  run  the  risk  of  including  the<iostream>header  more  than 
once  and  re-declaring  iostreams. 

The  compiler  considers  the  redeclaration  of  a structure  (this 
includes  both  struck  and  clasps)  to  bean  error,  since  it  would 
otherwise  allow  you  to  use  the  same  name  for  different  types.  To 
prevent  this  error  when  multiple  header  files  are  included,  you 
need  to  build  some  intelligence  into  your  header  files  using  the 
preprocessor  (Standard  C-H-header  files  like <iostream>al ready 
h ave  th  i s " i ntel  I i gen  ce" ) . 

Both  C and  C-H- allow  you  to  redeclare  a function,  as  long  as  the 
two  declarations  match,  but  neither  will  allow  the  redeclaration  of  a 
structure.  In  C-H-this  rule  is  especially  important  becauseif  the 


^However,  in  Standard  C-H-file  static  is  a deprecated  feature. 
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compiler  allowed  you  to  redeclare  a structure  and  the  two 
declarations  differed,  which  one  would  it  use? 

The  problem  of  redeclaration  comes  up  quite  a bit  in  C++ because 
each  data  type  (structure  with  functions)  generally  has  its  own 
header  file,  and  you  have  to  include  one  header  in  another  if  you 
want  to  create  another  data  type  that  uses  the  f i rst  one.  I n any  cpp 
file  in  your  project,  it's  likely  that  you'll  include  several  files  that 
includethe  same  header  file.  During  a single  compilation,  the 
compiler  can  see  the  same  header  file  several  times.  Unless  you  do 
someth  i ng  about  i t,  the  compi  I er  w i 1 1 see  the  reded  arati  on  of  you  r 
structure  and  report  a compi  I e-time  error.  To  solve  the  problem, 
you  need  to  know  a bit  more  about  the  preprocessor. 

The  preprocessor  directives 
#define,  #ifdef,  and  #endif 

The  preprocessor  directive  #definecan  be  used  to  create  compile- 
time flags.  You  have  two  choices:  you  can  simply  tell  the 
preprocessor  that  the  flag  is  defined,  without  specifying  a value: 

I #define  FLAG 

or  you  can  give  it  a value  (which  isthe typical  C way  to  define  a 
constant): 

I #define  PI  3.14159 

I n either  case,  the  label  can  now  be  tested  by  the  preprocessor  to  see 
if  it  has  been  defined: 

I #ifdef  FLAG 

This  will  yield  a true  result,  and  the  code  foil  owing  the#ifdefwill 
be  included  in  the  package  sent  to  the  compiler.  This  inclusion 
stops  when  the  preprocessor  encounters  the  statement 

I #endif 
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or 

I #endif  //  FLAG 

Any  non-comment  after  the #endif  on  the  same  line  is  illegal,  even 
though  some  compilers  may  accept  it.The#ifde®'  #endif  pairs 
may  be  nested  within  each  other. 

Thecomplement  of  #defineis#undef  (short  for  "un-define”), 
which  will  makean  #ifdef  statement  using  the  same  variable  yield 
a false  result.  #undefwill  also  cause  the  preprocessor  to  stop  using 
a macro.  The  complement  of  #ifdef  is  #ifndef,  which  will  yield  a 
true  if  the  label  has  not  been  defined  (this  isthe  one  we  will  use  in 
header  files). 

There  are  other  useful  features  in  theC  preprocessor.  You  should 
check  your  local  documentation  for  the  full  set. 

A standard  for  header  files 

In  each  header  filethat  contains  a structure,  you  should  first  check 
to  see  if  this  header  has  already  been  included  in  this  particular  cpp 
file.  You  do  this  bytesting  a preprocessor  flag.  If  theflag  isn't  set, 
thefile  wasn't  included  and  you  should  set  the  flag  (so  the 
structure  can't  get  re-declared)  and  declare  the  structure.  If  theflag 
was  set  then  that  type  has  already  been  declared  so  you  should  just 
I gnore  the  code  that  deci ares  it.  H ere's  how  the  header  f 1 1 e shou I d 
look: 

#ifndef  HEADER_FLAG 
#define  HEADER_FLAG 
//  Type  declaration  here... 

#endif  //  HEADER_FLAG 

Asyou  can  see,  the  first  time  the  header  file  is  included,  the 
contentsof  the  header  file  (including  your  type  declaration)  will  be 
included  by  the  preprocessor.  All  the  subsequent  times  it  is 
included  - in  a single  compilation  unit- the  type  declaration  will 
be  ignored.  The  name  HEADER_FLAG  can  beany  unique  name. 
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but  a rel  i abl  e standard  to  fol  I ow  i s to  capital  i ze  the  name  of  the 
header  file  and  replace  periods  with  underscores  (leading 
underscores,  however,  are  reserved  for  system  names).  H ere's  an 
example: 

//:  C04 : Simple . h 

//  Simple  header  that  prevents  re-definition 
#ifndef  SIMPLE_H 
#define  SIMPLE_H 

struct  Simple  { 
int  i,j,k; 

initialize  0 { i = j = k = 0;  } 

}; 

#endif  //  SIMPLE_H  ///:- 

Although  the  SI  M PLE_H  after  the  #endif  is  commented  out  and 
thus  ignored  by  the  preprocessor,  it  is  useful  for  documentation. 

These  preprocessor  statements  that  prevent  multiple  inclusion  are 
often  referred  to  as  include  guards. 

Namespaces  in  headers 

You'll  notice  that  using  d/'rect/Ves  are  present  in  nearly  all  thecpp 
files  in  this  book,  usually  in  theform: 

I using  namespace  std; 

Sincestd  is  the  namespace  that  surrounds  the  entire  Standard  C++ 
library,  this  particular  using  directive  allows  the  names  in  the 
Standard  C++library  to  beused  without  qualification.  However, 
you'll  virtually  never  see  a using  directive  in  a header  file  (at  least, 
not  outside  of  a scope).  The  reason  is  that  the  using  directive 
ell  mi  nates  the  protect!  on  of  that  particular  namespace,  and  the 
effect  lasts  until  the  end  of  the  current  compilation  unit.  If  you  put 
a using  directive(outsideof  a scope)  in  a header  file,  it  means  that 
this  loss  of  "namespace  protection"  will  occur  with  anyfilethat 
includesthis  header,  which  often  means  other  header  files.  Thus,  if 
you  start  putting  using  directives  in  header  files,  it's  very  easy  to 
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end  up  "turning  off"  namespaces  practically  everywhere,  and 
thereby  neutralizing  the  beneficial  effects  of  namespaces. 

In  short:  don't  put  using  directives  in  header  files. 

Using  headers  in  projects 

When  building  a project  in  C++,  you'll  usually  create  it  by  bringing 
together  a lot  of  different  types  (data  structures  with  associated 
functions).  You'll  usually  put  the  declaration  for  each  type  or  group 
of  associated  typesin  a separate  header  file,  then  define  the 
functions  for  that  type  in  atranslation  unit.  When  you  use  that 
type,  you  must  includethe  header  fileto  perform  the  declarations 
properly. 

Someti  mes  that  pattern  will  be  foil  owed  in  this  book,  but  more 
often  the  examples  will  bevery  small,  so  everything  - the  structure 
declarations,  function  definitions,  and  themain(  )function  - may 
appear  in  a single  file.  However,  keep  in  mind  that  you'll  want  to 
use  separate  files  and  header  files  in  practice. 


Nested  structures 

The  convenience  of  taking  data  and  function  names  out  of  the 
global  name  space  extends  to  structures.  You  can  nest  a structure 
within  another  structure,  and  therefore  keep  associated  elements 
together.  The  declaration  syntax  is  what  you  would  expect,  as  you 
can  see  in  the  following  structure,  which  implements  a push-down 
stack  asa  simple  linked  list  so  it  "never"  runs  out  of  memory: 

// : C04 : Stack  . h 

//  Nested  struct  in  linked  list 
#ifndef  STACK_H 
#define  STACK_H 

struct  Stack  { 
struct  Link  { 
void*  data; 
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Link*  next; 

void  initialize (void*  dat.  Link*  nxt); 

}*  head; 

void  initialize  0 ; 
void  push (void*  dat); 
void*  peek  ( ) ; 
void*  pop  ( ) ; 
void  cleanup  ( ) ; 

}; 

#endif  //  STACK_H  ///:- 

The  nested  struct!  s called  Link,  and  it  cental  ns  a pointer  to  the 
next  Link  in  the  list  and  a pointer  to  the  data  stored  intheLink.  If 
the  next  pointer  iszero,  it  means  you're  at  the  end  of  the  list. 

N otice  that  the  head  poi  nter  is  defi  ned  right  after  the  declaration 
for  struct  Link  instead  of  a separate  definition  Link*  head  This  is 
a syntax  that  came  from  C,  but  it  emphasizes  the  i mportance  of  the 
semicolon  after  the  structure  declaration;  the  semicolon  indicates 
the  end  of  the  comma-separated  listof  definitions  of  that  structure 
type.  (Usually  the  list  is  empty.) 

The  nested  structure  has  its  own  initiaiize(  )funrtion,  likeall  the 
structures  presented  so  far,  to  ensure  proper  initialization.  Stack 
has  both  an  initiaiize(  )and  cieanup(  Kunction,  as  well  aspush( ) 
which  takes  a poi  nter  to  the  data  you  wish  to  store  (it  assumes  this 
has  been  allocated  on  the  heap),  and  pop(  1 which  returns  the  data 
poi  nter  from  the  top  of  the  Stack  and  removes  the  top  el  ement. 
(When  you  pop(  )an  element,  you  are  responsible  for  destroying 
the  object  pointed  to  by  the  data)  Thepeek(  )fu  notion  also  returns 
the  data  poi  nter  from  the  top  element,  but  it  I eaves  the  top  element 
on  the  Stack. 

H ere  are  the  defi  ni  ti  ons  for  the  member  fu  ncti  ons: 

//:  C04 : Stack . cpp  {0} 

//  Linked  list  with  nesting 
#include  "Stack. h" 

#include  ".. /require . h" 
using  namespace  std; 
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void 

Stack :: Link :: initialize (void*  dat.  Link*  nxt)  { 
data  = dat; 
next  = nxt ; 

} 

void  Stack :: initialize  ( ) { head  = 0;  } 

void  Stack :: push (void*  dat)  { 

Link*  newLink  = new  Link; 
newLink->initialize (dat,  head); 
head  = newLink; 

} 

void*  Stack :: peek ( ) { 

require (head  !=  0,  "Stack  empty"); 
return  head->data; 

} 

void*  Stack: :pop()  { 

if (head  ==  0)  return  0; 
void*  result  = head->data; 

Link*  oldHead  = head; 
head  = head->next; 
delete  oldHead; 
return  result; 

} 

void  Stack :: cleanup ( ) { 

require (head  ==  0,  "Stack  not  empty"); 

} ///:- 

The  first  (definition  is  parti  cuiariy  interesting  because  it  shows  you 
how  to  (define a member  of  a neste(d  strurture.  You  simpiy  use  an 
a(d(ditionai  ievei  of  scope  resoiuti on  to  specify  the  name  of  the 
enciosing  struct  Stack::Link::initialize(t^kes  the  arguments  an(d 
assigns  them  to  its  members. 

Stack::initialize(  ^etsheadtozero,  sotheobjert  knows  it  has  an 
empty  iist. 
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Stack::push(  Jtakes  the  argument,  which  is  a pointer  to  the  variable 
you  want  to  keep  track  of,  and  pushes  it  on  the  Stack  Fi  rst,  it  uses 
new  to  al  I ocate  storage  for  the  L i nk  i t w i 1 1 i nsert  at  the  top.  Then  it 
cal  I s L i n k's  i n i ti al  i ze(  ]fu  net!  on  to  assi  gn  the  appropri  ate  val  ues  to 
the  members  of  the  Link.  Noticethat  the  next  pointer  isassigned  to 
the  current  head;  then  head  isassigned  to  the  new  Link  pointer. 
This  effectively  pushes  the  Link  in  at  the  top  of  the  list. 

Stack::pop(  )captures  the  data  poi  nter  at  the  current  top  of  the 
Stack;  then  it  moves  the  head  pointer  down  and  deletes  the  old  top 
of  the  Stack,  finally  returning  the  captured  pointer.  When  pop( ) 
removes  the  I ast  el  ement,  then  head  agai  n becomes  zero,  meani  ng 
the  Stack  is  empty. 

Stack::cieanup(  )doesn't  actually  do  any  cleanup.  Instead,  it 
establishes  a firm  policy  that  "you  (the client  programmer  using 
this  Stack  object)  are  responsible  for  popping  all  the  elements  off 
this  Stack  and  deleting  them."  Therequire(  )isused  to  indicate 
that  a programming  error  has  occurred  if  the  Stack  is  not  empty. 

Why  couldn't  the  Stack  destructor  be  responsi  ble  for  al  I the  objects 
that  the  client  programmer  didn't  pop(  J?  The  problem  is  that  the 
Stack  is  holding  void  pointers,  and  you'll  learn  in  Chapter  13  that 
calling  deletefor  a void* doesn't  clean  things  up  properly.  The 
subject  of  "who's  responsi  ble  for  the  memory"  is  not  even  that 
si mpl e,  as  we'l  I see  i n I ater  chapters. 

H ere's  an  exampi  e to  test  the  Stack: 

//:  C04 : StackTest . epp 

//{L}  Stack 

//{T}  StackTest . epp 

//  Test  of  nested  linked  list 

#include  "Stack. h" 

#include  ".. /require . h" 

#include  <fstream> 

#include  <iostream> 

#include  <string> 
using  namespace  std; 
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int  main(int  argc,  char*  argv [ ] ) { 

requireArgs (argc,  1);  //  File  name  is  argument 
ifstream  in(argv[l]); 
assure  (in,  argv[l]); 

Stack  textlines; 
textlines.initializeO  ; 
string  line; 

//  Read  file  and  store  lines  in  the  Stack: 
while (getline  (in,  line)) 

textlines . push (new  string (line) ) ; 

//  Pop  the  lines  from  the  Stack  and  print  them: 
string*  s; 

while((s  = ( string* ) text lines . pop  0 ) !=  0)  { 

cout  <<  *s  <<  endl; 
delete  s; 

} 

textlines . cleanup ( ) ; 

} ///:- 

Thi  s i s si  mi  I ar  to  the  eari  i er  exampi  e,  but  it  pushes  i i nes  from  a f i i e 
(as  string  pointers)  on  the  Stack  an(d  then  pops  them  off,  which 
resuits  in  the  fiie  being  printed  out  in  reverse  order.  Note  that  the 
pop( ) member  function  returns  a void* and  this  must  be  cast  back 
to  a stri  ng* before  it  can  be  used . To  pri  nt  the  stri  ng  the  poi  nter  i s 
dereferenced. 

Astextiinesis  being  fiiied,  the  contents  of  iineis  "cioned"  for  each 
push(  )by  making  a new  stri ng(iine)Thevaiue  returned  from  the 
new-expression  is  a pointer  to  the  new  stringthat  was  created  and 
that  copied  the  information  from  iine  if  you  had  simpiy  passed  the 
address  of  iineto  push( ) you  wouid  end  up  with  aStackfiiied 
with  identicai  addresses,  aii  pointing  to  iine  You'ii  iearn  more 
about  this  "cioning"  process  iater  in  the  book. 

The  fiie  name  is  taken  from  the  command  iine.  To  guarantee  that 
there  are  enough  arguments  on  the  command  iine,  you  see  a 
second  function  used  from  the require.hheader  fiie: 
requireArgs(  )which  compares  argcto  the  desired  number  of 


270 


Thinking  in  C+  + 


www.BruceEckel.com 


arguments  and  prints  an  appropriate  error  message  and  exits  the 
program  if  there  aren't  enough  arguments. 

Global  scope  resolution 

The  scope  resolution  operator  gets  you  out  of  situations  in  which 
the  namethe  compiler  chooses  by  default  (the  "nearest"  name)  isn't 
what  you  want.  For  example,  suppose  you  have  a structure  with  a 
local  identifier  a,  and  you  want  to  select  a global  identifier  a from 
i nsi  de  a member  fu ncti  on.  The  compi  I er  wou  I d defau It  to  choosi  ng 
the  local  one,  so  you  must  tell  it  to  do  otherwise.  When  you  want  to 
specify  a global  name  using  scope  resolution,  you  use  the  operator 
with  nothing  in  front  of  it.  Here's  an  example  that  shows  global 
scope  resolution  for  both  a variable  and  a function: 

//:  C04 : Scoperes . cpp 
//  Global  scope  resolution 
int  a; 
void  f ( ) { } 

struct  S { 
int  a; 
void  f ( ) ; 

}; 


void  S : : f ( ) { 

::f();  //  Would  be  recursive  otherwise! 

::a++;  //  Select  the  global  a 

a — ; //  The  a at  struct  scope 

} 

int  mainO  { S s;  f();  } ///:- 

Without  scope  resolution  in  S::f( ) the  compiler  would  defauitto 
selecting  the  member  versions  of  f(  )and  a. 


Summary 

In  this  chapter,  you've  learned  the  fundamental  "twist"  of  C++: 
that  you  can  place  functions  insideof  structures.  This  new  type  of 
structure  is  cal  led  an  abstract  data  type,  and  variables  you  create 
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using  this  structure  are  cal  led  objects,  or  instances,  of  that  type. 
Calling  a mennber  function  for  an  object  is  called  sending  a message 
to  that  object.  The  primary  action  in  object-oriented  programming 
is  sending  messages  to  objects. 

Although  packaging  data  and  functions  together  is  a significant 
benefit  for  code  organization  and  makes  library  use  easier  because 
it  prevents  name  clashes  by  hiding  the  names,  there's  a lot  more 
you  can  do  to  make  programming  safer  in  C-H-.  I n the  next  chapter, 
you'll  learn  how  to  protect  some  members  of  a structso  that  only 
you  can  man  i pul  ate  them.  This  establishes  a cl  ear  boundary 
between  what  the  user  of  the  structure  can  change  and  what  only 
the  programmer  may  change. 


Exercises 

Solutions  to  selected  exercises  can  be  found  in  the  electronic  document  TheThinking  in  C++ Annotated 
Solution  Guide,  aval  I able  for  a small  fee  from  http://www.BruceEckel.com. 

1.  In  the  Standard  C library,  thefunction  puts(  )prints  a 
char  array  to  the  console  (so  you  can  say  putsC'hello"). 
Write  a C program  that  uses  puts(  )but  does  not  include 
<stdio.h>or  otherwise  declare  thefunction.  Compilethis 
program  with  yourC  compiler.  (Some  C-H- compilers  are 
not  distinct  from  theirC  compilers;  in  thiscaseyou  may 
need  to  d i scover  a command-1  i ne  f I ag  that  forces  a C 
compilation.)  Now  compileit  with  the  C-H- compiler  and 
note  the  difference. 

2.  Createastructdeclaration  with  a single  member 
function,  then  create  a defi  nition  for  that  member 
function.  Create  an  object  of  your  new  datatype,  and  call 
the  member  function. 

3.  Changeyour  solution  to  Exercise  2 so  the  structis 
declared  in  a properly  "guarded"  header  file,  with  the 
definition  in  onecppfileand  your  main(  )in  another. 
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4.  Create  a structwith  a single  intdata  member,  and  two 
global  functions,  each  of  which  takes  a pointer  to  that 
struct  The  f i rst  f u ncti  on  has  a second  i nt  argu  ment  and 
sets  the  structs  i ntto  the  argument  val  ue,  the  second 

d i spl ays  the  i ntfrom  the  struct  T est  the  fu ncti ons. 

5 . Repeat  Exerci  se  4 but  move  the  fu  ncti  ons  so  they  are 
member  functions  of  the  struct  and  test  again. 

6.  Create  a cl  ass  that  (redundantly)  performs  data  member 
selection  and  a member  function  call  using  the  this 
keyword  (which  refersto  the  address  of  the  current 
object). 

7.  Make  a Stash  that  holds  doubles.  Fill  it  with  25  double 
values,  then  print  them  out  to  the  console. 

8 . Repeat  Exerci  se  7 w i th  Stack. 

9.  Create  a file  containing  a function  f(  )that  takes  an  int 
argument  and  prints  it  to  the  console  using  theprintf( ) 
function  in  <stdio.h>by  saying:  printf("%d\  n",  i)n 
which  I istheintyou  wish  to  print.  Create  a separate  file 
containing  main( ) and  in  this  file  declare  f(  )totakea 
floatargument.  Call  f(  )from  inside main( ) Try  to 
compileand  link  your  program  with  the  C++ compiler 
and  see  what  happens.  Now  compileand  I ink  the 
program  using  the  C compiler,  and  see  what  happens 
when  it  runs.  Explain  the  behavior. 

10.  Find  out  how  to  produce  assembly  languagefromyour  C 
and  C++compilers.  Write  a function  inC  and  a struct 
with  a single  member  function  in  C++.  Produce  assembly 
language  from  each  and  find  the  function  names  that  are 
produced  by  your  C function  and  your  C++ member 
function,  so  you  can  see  what  sort  of  name  decoration 
occurs  inside  the  compiler. 

11.  Writea  program  with  conditionally-compiled  codein 
maln( ) so  that  when  a preprocessor  value  is  defined  one 
message  is  printed,  but  when  it  is  not  defined  another 
message  i s pri  nted . Compi I e thi s code  experi  menti ng 
with  a#deflnewithin  theprogram,  then  discover  the 
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way  your  compi ler  takes  preprocessor  defi nitions  on  the 
command  line  and  experiment  with  that. 

12.  Writea  program  that  usesassert(  )with  an  argument  that 
is  always  false  (zero)  to  see  what  happens  when  you  run 
it.  Now  compile  it  with  #define  NDEBUGand  run  it 
agai  n to  see  the  d ifference. 

13.  Create  an  abstract  data  type  that  represents  a videotape 
in  a video  rental  store.  Try  to  consider  all  the  data  and 
operations  that  may  be  necessary  for  the  Videotype  to 
work  well  within  the  video  rental  management  system. 
Includea  print(  )member  function  that  displays 
information  about  the  Video 

14.  Create  a Stack  object  to  hold  the  Video  objects  from 
Exercise  13.  Create  several  Videoobjects,  store  them  in 
the  Stack,  then  display  them  using  Video::print( ) 

15.  Writea  program  that  printsoutall  the  sizes  for  the 
fundamental  data  types  on  your  computer  using  sizeof. 

16.  Modify  Stash  to  usea  vector<char>as  its  underlying 
data  structure. 

17.  Dynamically  create  pieces  of  storage  of  thefol  lowing 
types,  using  new:  int  iong  an  array  of  100 chats,  an 
array  of  lOOfioafe.  Print  the  addresses  of  these  and  then 
free  the  storage  using  deiete 

18.  Write  a function  that  takes  a char* argument.  Using  new, 
dynamically  allocate  an  array  of  charthat  is  the  size  of 
thechararray  that's  passed  to  the  function.  Using  array 
indexing,  copy  the  characters  from  the  argument  to  the 
dynamically  allocated  array  (don't  forget  the  null 
terminator)  and  return  the  poi nter  to  the  copy.  In  your 
main( ) test  the  function  by  passing  a static  quoted 
character  array,  then  take  the  result  of  that  and  pass  it 
back  into  the  function.  Print  both  strings  and  both 
pointers  so  you  can  see  they  are  different  storage.  Using 
delete  clean  up  all  the  dynamic  storage. 

19.  Show  an  exampleof  a structure  declared  within  another 
structure(a  nested  structure).  Declaredata  members  in 
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both  struck,  and  declare  and  definemennber  functions  in 
both  struck.  Write  a main(  )that  tests  your  new  types. 

20.  How  big  is  a structure?  Write  a piece  of  codethat  prints 
thesizeof  various  structures.  Create  structures  that  have 
data  mennbers  only  and  ones  that  have  data  mennbers 
and  function  mennbers.  Then  create  a structure  that  has 
no  members  at  all.  Print  out  the  sizes  of  all  these.  Explain 
the  reason  for  the  result  of  the  structure  with  no  data 
members  at  al  I . 

21.  C++  automati cal  I y creates  the  equ i val ent  of  a ty pedef for 
struck,  as  you've  seen  in  this  chapter.  It  also  does  this  for 
enumerations  and  unions.  Write  a small  program  that 
demonstrates  this. 

22.  CreateaStackthatholdsStashes.  Each  Stashwill  hold 
five  lines  from  an  input  file.  Create  the  Stashes  using 
new.  Read  a file  into  your  Stack,  then  reprint  it  in  its 
original  form  by  extracting  it  from  the  Stack 

23.  M od  ify  Exerci se  22  so  that  you  create  a structthat 
encapsulates  the  Stack  of  Stashes.  The  user  should  only 
add  and  get  lines  via  member  functions,  but  under  the 
covers  the  structhappens  to  use  a Stack  of  Stashes. 

24.  Create  a structthat  holds  an  intand  a pointer  to  another 
instance  of  the  same  struct  Write  a function  that  takes 
theaddressof  one  of  these  struck  and  an  intindicating 
the  length  of  the  list  you  want  created.  This  function  will 
make  a whole  chain  of  these  struck  (a  linked  list),  starting 
from  the  argument  (the /lead  ofthe  list),  with  each  one 
poi  nti  ng  to  the  next.  M ake  the  new  struck  usi  ng  new, 
and  put  the  count  (which  object  number  this  is)  intheint 
I n the  I ast  struct!  n the  I i st,  put  a zero  val  ue  i n the  poi  nter 
to  indicate  that  it's  the  end.  Write  a second  function  that 
takes  the  head  of  your  list  and  moves  through  to  the  end, 
printing  out  both  the  poi  nter  value  and  theintvaluefor 
each  one. 

25.  Repeat  Exercise 24,  but  putthefunctions  insideastruct 
instead  of  using  "raw"  struck  and  functions. 
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5:  Hiding  the 
i mpiementation 

A typical  C library  contains  a structand  some 
associated  functions  to  act  on  that  struct  So  far, 
you've  seen  how  C++  takes  functions  that  are 
conceptually  associated  and  makes  them  literally 
associated  by 
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putti  ng  the  fu  ncti  on  deci  arati  ons  i nsi  de  the  scope  of  the  struct 
changi  ng  the  way  fu  ncti  ons  are  cal  I ed  for  the  struct  el  I mi  nati  ng  the 
passing  of  the  structure  ad  dress  as  the  first  argument,  and  adding  a 
new  type  name  to  the  program  (so  you  don't  have  to  create  a 

typedef  for  the  structtag). 

These  are  all  convenient- they  help  you  organize  your  codeand 
make  it  easier  to  write  and  read.  However,  there  are  other 
important  issues  when  making  libraries  easier  in  C++,  especially 
the  issues  of  safety  and  control . This  chapter  looks  at  the  subject  of 
boundaries  in  structures. 


Setting  limits 

In  any  relationship  it's  important  to  have  boundaries  that  are 
respected  by  all  parties  involved.  When  you  create  a library,  you 
establish  a relationship  with  the  client  programmer  who  uses  that 
library  to  build  an  application  or  another  library. 

In  a C struct  as  with  most  things  in  C,  there  are  no  rules.  Client 
programmers  can  do  anything  they  want  with  that  struct  and 
there's  no  way  to  force  any  particular  behaviors.  For  example,  even 
though  you  saw  in  the  last  chapter  the  importance  of  the  functions 
named  initialize(  )and  cleanup!  )the  client  programmer  has  the 
option  not  to  call  those  functions.  (We'll  look  at  a better  approach 
i n the  next  chapter.)  And  even  though  you  would  really  prefer  that 
the  cl  lent  programmer  not  directly  manipulate  some  of  the 
members  of  your  struct  in  C there's  no  way  to  prevent  it. 
Everything's  naked  to  the  world. 

There  are  two  reasons  for  control  I i ng  access  to  members.  The  fi  rst  is 
to  keep  the  client  programmer's  hands  off  tools  they  shouldn't 
touch,  toolsthat  are  necessary  for  the  internal  machinations  of  the 
data  type,  but  not  part  of  the  interface  the  client  programmer  needs 
to  solve  their  particular  problems.  This  is  actually  a service  to  client 
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programmers  because  they  can  easily  see  what's  important  to  them 
and  what  they  can  ignore. 

The  second  reason  for  access  control  isto  allow  the  library  designer 
to  change  the  i nternal  work!  ngs  of  the  structu  re  without  worry!  ng 
about  how  it  will  affect  the  cl  lent  programmer.  In  the  Stack 
example  in  the  last  chapter,  you  might  want  to  al  locate  the  storage 
in  big  chunks,  for  speed,  rather  than  creating  new  storage  each  time 
an  element  is  added.  If  the  interface  and  implementation  are  clearly 
separated  and  protected,  you  can  accomplish  this  and  require  only 
a relink  by  the  cl  lent  programmer. 


C++  access  control 

C++ introduces  three  new  keywords  to  set  the  boundaries  in  a 
structure:  public  private  and  protected  Their  use  and  meaning 
are  remarkably  straightforward.  These  access  specifiers  are  used  only 
in  a structure  declaration,  and  they  changetheboundary  for  all  the 
declarations  that  follow  them.  Whenever  you  use  an  access 
specifier,  it  must  befollowed  by  a colon. 

publicmeansall  member  declarations  that  follow  are  aval  I able  to 
everyone,  publicmembers  arelikestructmembers.  For  example, 
the  fol  I ow  i ng  structd  eel  arati  ons  are  i denti  cal : 

//:  COS : Public . epp 

//  Public  is  just  like  C's  struct 

struct  A { 
int  i ; 
char  j; 
float  f; 
void  f unc ( ) ; 

}; 


void  A : : f unc ( ) { } 

struct  B { 
public : 
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int  i ; 
char  j; 
float  f; 
void  f unc ( ) ; 


void  B : : f unc ( ) { } 

int  main  ( ) { 

A a;  B b; 
a . i = b . i = 1 ; 
a.j  = b.j  = 'c'; 
a.f  = b.f  = 3.14159; 
a . f unc ( ) ; 
b . f unc ( ) ; 

} ///:- 

Theprivatekeyword,  on  the  other  hand,  means  that  no  one  can 
access  that  member  except  you,  the  creator  of  the  type,  inside 
function  members  of  that  type,  privateisa  brick  wall  between  you 
and  the  cl  lent  programmer;  if  someone  tries  to  access  a private 
member,  they'l  I get  a compi  le-ti  me  error.  I n struct  B i n the  example 
above,  you  may  want  to  make  portions  of  the  representation  (that 
is,  the  data  members)  hidden,  accessible  only  to  you: 

//:  COS : Private . cpp 
//  Setting  the  boundary 

struct  B { 
private : 
char  j; 
float  f; 
public : 
int  i ; 

void  f unc  ( ) ; 

}; 


void  B : : f unc ( ) { 

i = 0; 

j = 'O'; 
f = 0.0; 
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int  main  ( ) { 

B b; 

b.i  = 1;  //  OK,  public 

//!  b.j  = //  Illegal,  private 

//!  b.f  = 1.0;  //  Illegal,  private 
} ///:- 

Although  func(  )can  access  any  mennber  of  B (because func(  )isa 
mennber  of  B,  thus  automatically  granting  it  permission),  an 
ordinary  global  function  likemain(  )cannot.  Of  course,  neither  can 
member  functions  of  other  structures.  Only  the  functions  that  are 
clearly  stated  in  the  structure  declaration  (the  "contract")  can  have 
access  to  privatemembers. 

There  is  no  required  order  for  access  specifiers,  and  they  may 
appear  more  than  once.  They  affect  all  the  members  declared  after 
them  and  before  the  next  access  specifier. 

protected 

The  last  access  specifier  is  protected  protectedactsjust  like 
private  with  one  except! on  that  wecan't  really  talk  about  right 
now:  "Inherited"  structures  (which  cannot  access  privatemembers) 
are  granted  accesstoprotectedmembers.  This  will  become  clearer 
in  Chapter  14  when  inheritance  is  introduced.  For  current 
purposes,  consider  protectedto  be  just  I ike  private 


Friends 

What  if  you  want  to  explicitly  grant  access  to  a function  that  isn't  a 
member  of  the  current  structure?  This  is  accomplished  by  declaring 
that  function  a friend /ns/cfethe  structure  declaration.  It's  important 
that  the  f ri  end  d eel  arati  on  occu  rs  i nsi  de  the  structu  re  deci  arati  on 
because  you  (and  the  compiler)  must  be  able  to  read  the  structure 
declaration  and  see  every  rule  about  the  size  and  behavior  of  that 
datatype.  And  a very  important  rule  in  any  relationship  is,  "Who 
can  access  my  private  implementation?" 
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The  class  controls  which  code  has  access  to  its  mennbers.  There's  no 
magic  way  to  "break  in"  from  the  outside  if  you  aren't  a friend; 
you  can't  declare  a new  class  and  say,  "Hi,  I'm  a friend  of  Bob!" 
and  expect  to  seethe  privateand  protected  members  of  Bob. 

You  can  declare  a global  function  as  a friend  and  you  can  also 
declare  a member  function  of  another  structure,  or  even  an  entire 
structure,  as  a friend  H ere's  an  example : 

//:  COS :Friend. cpp 

//  Friend  allows  special  access 

//  Declaration  (incomplete  type  specification): 
struct  X; 

struct  Y { 
void  f (X* ) ; 

}; 

struct  X { //  Definition 
private : 
int  i ; 
public : 

void  initialize ()  ; 

friend  void  g(X*,  int);  //  Global  friend 
friend  void  Y::f(X*);  //  Struct  member  friend 

friend  struct  Z;  //  Entire  struct  is  a friend 
friend  void  h(); 

}; 


void  X :: initialize  ( ) { 

i = 0; 

} 


void  g (X*  X,  int  i)  { 
x->i  = i; 

} 


void  Y : : f (X*  x)  { 
x->i  = 47; 

} 

struct  Z { 
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private : 
int  j ; 
public : 

void  initialize  0 ; 
void  g (X*  x) ; 

}; 


void  Z :: initialize  ( ) { 

j = 99; 

} 


void  Z : : g (X*  x)  { 
x->i  +=  j; 

} 

void  h()  { 

X X ; 

x.i  = 100;  //  Direct  data  manipulation 

} 

int  main  ( ) { 

X X ; 

Z z ; 

z . g (&x) ; 

} ///:- 

Struct  Y has  a member  function  f(  )thatwill  modify  an  object  of 
typeX.  Thisisa  bit  of  a conundrum  because  the  C++ compiier 
requires  you  to  deci  are  everything  before  you  can  refer  to  it,  so 
struct  Ymust  bedeciared  before  its  member  Y::f(X*)can  be 
deciared  asafriend  instructX  But  for  Y::f(X*)to  bedeciared, 
struct  Xmust  bedeciared  first! 

H ere's  the  soi  ution.  N otice  that  Y ::f  (X*)takes  the  address  of  an  X 
object.  This  iscriticai  because  the  compiier  aiways  knows  how  to 
pass  an  address,  which  is  of  a fixed  size  regardiess  of  the  object 
being  passed,  even  if  it  doesn't  havefuii  information  about  the  size 
of  the  type,  if  you  try  to  pass  the  whoie  object,  however,  the 
compiier  must  seethe  entire  structure  definition  of  X,  to  know  the 
size  and  how  to  pass  it,  before  it  ai  iows  you  to  deci  are  a function 
such  asY::  g(X) 
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By  passing  the  address  of  an  X,  the  compiler  allows  you  to  make  an 
incomplete  type  specification  ofX  prior  to  declaringY::f(X*)Thisis 
accomplished  in  the  declaration: 

I struct  X; 

This  declaration  simply  tel  Is  the  compiler  there's  a structby  that 
name,  so  it's  OK  to  refer  to  it  as  long  as  you  don't  require  any  more 
knowledge  than  the  name. 

Now,  in  struct  X the  functi  on  Y::f(X*)can  be  declared  as  a friend 
with  no  problem.  If  you  tried  to  declare  it  before  the  compiler  had 
seen  the  full  specification  forY,  it  would  have  given  you  an  error. 
Thi  s i s a safety  featu  re  to  ensu  re  cons!  stency  and  el  i mi  nate  bugs. 

N oti  ce  the  two  other  f riend  fu  ncti  ons.  The  f i rst  deci  ares  an 
ordinary  global  function  g(  )as  a friend  Butg(  )has  not  been 
previously  declared  at  the  global  scope!  It  turns  out  that  friend  can 
be  used  this  way  to  simultaneously  declare  the  functi  on  and  give  it 
friend  status.  This  extends  to  entire  structures: 

I friend  struct  Z; 

is  an  incomplete  type  specification  for  Z,  and  it  gives  the  entire 
str  u ctu  re  f ri  en  d statu  s. 

Nested  friends 

M aki  ng  a structure  nested  doesn't  automatical  I y give  it  access  to 
privatemembers.  To  accomplish  this,  you  mustfollow  a particular 
form:  first,  declare  (without  defining)  the  nested  structure,  then 
declare  it  as  a friend,  and  fi  nal  ly  defi  ne the  structure.  The  structure 
definition  must  be  separate  from  thefrienddeclaration,  otherwise 
it  would  be  seen  by  the  compiler  as  a non-member.  Here's  an 
example: 

//:  COS :NestFriend. cpp 
//  Nested  friends 
#include  <iostream> 
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#include  <cstring>  //  memsetO 
using  namespace  std; 
const  int  sz  = 20; 

struct  Holder  { 
private : 

int  a [ sz ] ; 
public : 

void  initialize  0 ; 
struct  Pointer; 
friend  Pointer; 
struct  Pointer  { 
private : 

Holder*  h; 
int*  p; 
public : 

void  initialize (Holder*  h)  ; 

//  Move  around  in  the  array: 

void  next  ( ) ; 

void  previous  0; 

void  top  ( ) ; 

void  end ( ) ; 

//  Access  values: 
int  read ( ) ; 
void  set (int  i) ; 


}; 


void  Holder :: initialize  ( ) { 

memset (a,  0,  sz  * sizeof  (int) ) ; 

} 

void  Holder :: Pointer :: initialize (Holder*  rv)  { 
h = rv; 
p = rv->a; 

} 

void  Holder :: Pointer :: next  ( ) { 

if (p  < &(h->a[sz  - 1]))  P++; 

} 

void  Holder :: Pointer :: previous ( ) { 

if (p  > & (h->a [0] ) ) p — ; 

} 
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void  Holder :: Pointer :: top ( ) { 

p = & (h->a  [0] ) ; 

} 

void  Holder :: Pointer :: end ( ) { 

p = & (h->a [ sz  - 1 ] ) ; 

} 

int  Holder :: Pointer :: read ( ) { 

return  *p; 

} 

void  Holder :: Pointer :: set ( int  i)  { 

*P  = i; 

} 

int  main  ( ) { 

Holder  h; 

Holder :: Pointer  hp,  hp2; 
int  i ; 

h . initialize  ( ) ; 
hp. initialize (&h) ; 
hp2.initialize(&h) ; 
for(i  = 0;  i < sz;  i++)  { 

hp . set  ( i ) ; 
hp . next  ( ) ; 

} 

hp .top  ( ) ; 
hp2 . end ( ) ; 

for(i  = 0;  i < sz;  i++)  { 

cout  <<  "hp  = " <<  hp.readO 

<<  ",  hp2  = " <<  hp2.read()  <<  endl; 
hp . next  ( ) ; 
hp2 . previous  ( ) ; 

} 

} ///:- 

Once  Pointeris  declared,  it  is  granted  access  to  the  private 
members  of  H older  by  saying: 

friend  Pointer; 
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The  struct  Hoi  deicontai  ns  an  array  of  infe  and  the  Pointer  allows 
you  to  access  them.  Because  Pointeris  strongly  associated  with 
Holder  it's  sensible  to  make  it  a member  structure  of  Holder  But 
because  Pointeris  a separate  cl  ass  from  Holder  you  can  make 
more  than  one  of  them  in  main(  )and  usethem  to  select  different 
parts  of  the  array.  Pointeris  a structure  instead  of  a raw  C pointer, 
so  you  can  guarantee  that  it  will  always  safely  point  insidethe 
Hoider 

The  Standard  C library  function  memset(  )(in  <cstring::^  isused 
for  convenience  in  the  program  above.  Itsetsall  memory  starting  at 
a particular  address  (the first  argument)  to  a particular  value  (the 
second  argument)  for  n bytes  past  the  starti  ng  address  (n  is  the 
third  argument).  Of  course,  you  could  have  simply  used  a loop  to 
iterate  through  all  the  memory,  but  memset(  )isavailable,  well- 
tested  (so  it's  less  likely  you'll  introduce  an  error),  and  probably 
more  efficient  than  if  you  coded  it  by  hand. 

I s it  pure? 

The  class  definition  gives  you  an  audit  trail,  so  you  can  see  from 
I ooki  ng  at  the  cl  ass  w hi  ch  fu  ncti  ons  have  permi  ssi  on  to  mod  i fy  the 
private  parts  of  the  cl  ass.  If  a function  is  a friend,  it  means  that  it 
isn't  a member,  but  you  want  to  give  permission  to  modify  private 
data  anyway,  and  it  must  be  listed  in  the  cl  ass  definition  so 
everyone  can  see  that  it's  one  of  the  privileged  functions. 

C-H- is  a hybrid  object-oriented  language,  not  a pure  one,  and 
friend  was  added  to  get  around  practical  problems  that  crop  up. 

It's  f i ne  to  poi  nt  out  that  this  makes  the  I anguage  I ess " pu  re," 
because  C-H-/S  designed  to  be  pragmatic,  not  to  aspire  to  an 
abstract  ideal. 
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Object  layout 

Chapter  4 Stated  that  a structwritten  for  a C compiler  and  later 
compiled  with  C++ would  be  unchanged.  This  referred  primarily 
to  the  object  I ayout  of  the  struct  that  I s,  where  the  storage  for  the 
individual  variables  is  positioned  in  the  memory  allocated  for  the 
object.  If  the  C++ compiler  changed  the  layout  of  C struct,  then 
any  C code  you  wrote  that  inadvisably  took  advantage  of 
knowl  edge  of  the  posit! ons  of  vari  abl  es  i n the  structwou I d break. 

When  you  start  using  access  specifiers,  however,  you've  moved 
completely  into  the  C++ realm,  and  things  change  a bit.  Within  a 
particular  "access  block"  (a  group  of  declarationsdelimited  by 
access  specifiers),  the  variables  are  guaranteed  to  be  laid  out 
contiguously,  as  in  C.  H owever,  the  access  blocks  may  not  appear 
in  the  object  in  the  order  that  you  declare  them.  Although  the 
compi  ler  will  usually  lay  the  blocks  out  exactly  as  you  see  them, 
there  is  no  rule  about  it,  because  a particular  machine  architecture 
and/  or  operating  environment  may  have  explicit  support  for 
privateand  protectedthat  might  require  those  blocks  to  be  placed 
in  special  memory  locations.  The  language  specification  doesn't 
want  to  restrict  this  kind  of  advantage. 

Access  specifiers  are  part  of  the  structure  and  don't  affect  the 
objects  created  from  the  structure.  A 1 1 of  the  access  specification 
information  disappears  before  the  program  is  run;  generally  this 
happens  during  compilation.  In  a running  program,  objects  become 
"regions  of  storage"  and  nothing  more.  If  you  really  want  to,  you 
can  break  all  the  rules  and  access  the  memory  directly,  as  you  can 
in  C.  C++is  not  designed  to  prevent  you  from  doing  unwise  things. 
It  just  provides  you  with  a much  easier,  highly  desirable 
alternative. 

In  general,  it's  not  a good  idea  to  depend  on  anything  that's 
implementation-specific  when  you're  writing  a program.  When 
you  must  have  implementation-specific  dependencies,  encapsulate 
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them  inside  a structure  so  that  any  porting  changes  are  focused  in 
one  place. 


The  class 

Access  control  is  often  referred  to  as  implementation  hiding. 

Including  functions  within  structures  (often  referred  to  as 
encapsulation^)  produces  a data  type  with  characteristics  and 
behaviors,  but  access  control  puts  boundaries  within  that  data  type, 
for  two  important  reasons.  The  first  is  to  establish  what  the  cl  lent 
programmers  can  and  can't  use.  You  can  build  your  internal 
mechanisms  i nto  the  structure  without  worry!  ng  that  cl  lent 
programmers  wi  1 1 thi  nk  that  these  mechani  sms  are  part  of  the 
interface  they  should  beusing. 

This  feeds  directly  into  the  second  reason,  which  is  to  separate  the 
interfacefrom  the  implementation.  If  the  structure  is  used  in  a set 
of  programs,  but  the  cl  i ent  programmers  can't  do  anyth!  ng  but 
send  messages  to  the  publicinterface,  then  you  can  change 
anything  that's  privatewithout  requiring  modifications  to  their 
code. 

Encapsulation  and  access  control,  taken  together,  invent  something 
more  than  a C struct  We're  now  in  the  world  of  object-oriented 
programming,  where  a structure  is  descr I bi  ng  a class  of  objects  as 
you  would  describe  a class  of  fishes  or  a class  of  birds:  Any  object 
belonging  tothisclass  will  share  these  character!  sties  and 
behaviors.  That's  what  the  structure  declaration  has  become,  a 
description  of  the  way  all  objects  of  this  type  will  look  and  act. 

In  the  original  OOP  language,  Simula-67,  thekeyword  classwas 
used  to  describe  a new  datatype.  This  apparently  inspired 
Stroustrup  to  choose  the  same  keyword  for  C-H-,  to  emphasize  that 


^ As  noted  before,  sometimes  access  control  is  referred  to  as  encapsulation. 
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this  was  the  focal  point  of  the  whole  language:  the  creation  of  new 
data  types  that  are  more  than  just  C struct  with  functions.  This 
certainly  seems  I ike  adequatejustification  for  a new  keyword. 

However,  the  use  of  cl  ass  in  C++ comes  close  to  being  an 
unnecessary  keyword.  It's  identical  tothestructkeyword  in 
absolutely  every  way  except  one:  cl  ass  defaults  to  private  whereas 
structdefaultsto  public  Here  are  two  structures  that  produce  the 
same  result: 

//:  COS : Class . cpp 

//  Similarity  of  struct  and  class 

struct  A { 
private : 

int  i,  j,  k; 
public : 
int  f ( ) ; 
void  g ( ) ; 

}; 


int  A : : f ( ) { 

return  i + j + k; 

} 


void  A : : g ( ) { 

i = j = k = 0; 

} 

//  Identical  results  are  produced  with: 

class  B { 

int  i,  j,  k; 

public : 
int  f ( ) ; 
void  g ( ) ; 

}; 


int  B:  : f 0 { 

return  i + j + k; 

} 


void  B : : g ( ) { 
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i = j = k = 0; 

} 

int  main  ( ) { 

A a; 

B b; 

a. f();  a.gO; 

b. f();  b.gO; 

} ///:- 

The  cl  ass  is  the  fundamental  OOP  concept  in  C++.  Itisoneofthe 
keywords  that  will  not  be  set  in  bold  in  this  book  - it  becomes 
annoying  with  a word  repeated  as  often  as  "class."  The  shift  to 
classes  is  so  important  that  I suspect  Stroustrup's  preference  would 
have  been  to  throw  structout  altogether,  but  the  need  for 
backwards  compatibility  with  C wouldn't  allow  that. 

M any  peopi  e prefer  a sty  I e of  creati  ng  cl  asses  that  i s more  struct 
likethan  class-like,  because  you  overridethe"default-to-private' 
behavior  of  the  class  by  starting  out  with  publicelements: 

class  X { 
public : 

void  interf ace_function ( ) ; 
private : 

void  private_function ( ) ; 
int  internal_representation; 

}; 

The  logic  behind  this  is  that  it  makes  more  sense  for  the  reader  to 
see  the  members  of  i nterest  f i rst,  then  they  can  i gnore  anythi  ng  that 
says  private  Indeed,  the  only  reasons  all  the  other  members  must 
be  declared  in  the  cl  ass  at  all  are  so  the  compiler  knows  how  big  the 
objects  are  and  can  allocate  them  properly,  and  so  it  can  guarantee 
consistency. 

The  examples  in  this  book,  however,  will  put  the  privatemembers 
first,  I ike  this: 

class  X { 

void  private_function  ( ) ; 
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int  internal_representation; 
public : 

void  interf ace_function  ( ) ; 

}; 

Some  peopleeven  go  to  the  troubleof  decorating  theirown  private 
names: 

class  Y { 
public : 
void  f ( ) ; 
private : 

int  mX;  //  "Self-decorated"  name 

}; 

Because  mX  isai  ready  hidden  in  the  scope  of  Y,  them  (for 
"member")  is  unnecessary.  However,  in  projects  with  many  giobai 
variabies  (something  you  shouid  striveto  avoid,  but  which  is 
sometimes  inevitabiein  existing  projects),  it  is  heipfui  to  beabieto 
distinguish  inside  a member  function  definition  which  data  is 
giobai  and  which  is  a member. 

Modifying  Stash  to  use  access  controi 

it  makes  sense  to  take  the  exampies  from  Chapter  4 and  modify 
them  to  used  asses  and  access  controi . Notice  how  thedient 
programmer  portion  of  the  interface  is  now  deariy  distinguished, 
so  there's  no  possibiiity  of  dient  programmers  accidentaiiy 
manipuiating  a part  of  the  ci  ass  that  they  shouid  n't. 

// : COS : Stash . h 

//  Converted  to  use  access  control 
#ifndef  STASH_H 
#define  STASH_H 

class  Stash  { 

int  size;  //  Size  of  each  space 

int  quantity;  //  Number  of  storage  spaces 

int  next;  //  Next  empty  space 

//  Dynamically  allocated  array  of  bytes: 

unsigned  char*  storage; 

void  inflate (int  increase); 
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public : 

void  initialize (int  size); 
void  cleanup ( ) ; 
int  add (void*  element); 
void*  fetch (int  index); 
int  count  ( ) ; 

}; 

#endif  //  STASH_H  ///:- 

Theinflate(  Kunction  has  been  ma(deprivatebecauseit  is  used 
only  by  theadd(  )function  and  isthus  part  of  the  underlying 
implementation,  not  the  interface.  This  means  that,  sometime  later, 
you  can  change  the  underlying  implementation  to  use  a different 
system  for  memory  management. 

Other  than  the  name  of  the  i ncl  ude  f i I e,  the  header  above  i s the 
only  thing  that's  been  changed  for  this  example.  The 
implementation  file  and  test  file  are  the  same. 

Modifying  Stack  to  use  access  controi 

As  a second  example,  here's  the  Stackturned  into  a class.  Now  the 
nested  data  structure  is  private  which  is  nice  because  it  ensures 
that  the  cl  lent  programmer  will  neither  have  to  look  at  it  nor  be 
ableto  depend  on  theinternal  representation  of  the  Stack: 

// : COS : Stack2 . h 

//  Nested  structs  via  linked  list 
#ifndef  STACK2_H 
#define  STACK2_H 

class  Stack  { 
struct  Link  { 
void*  data; 

Link*  next; 

void  initialize (void*  dat.  Link*  nxt); 

}*  head; 
public : 

void  initialize () ; 
void  push (void*  dat); 
void*  peek ( ) ; 
void*  pop ( ) ; 
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void  cleanup  ( ) ; 


}; 

#endif  //  STACK2_H  ///:- 

As  before,  the  implementation  doesn't  change  and  so  it  is  not 
repeated  here.  The  test,  too,  isidenti  cal. The  only  thing  that's  been 
changed  is  the  robustness  of  the  cl  ass  interface.  The  real  value  of 
access  control  is  to  prevent  you  from  crossing  boundaries  during 
development.  In  fact,  the  compiler  is  the  only  thing  that  knows 
about  the  protection  level  of  class  members.  There  is  no  access 
control  information  mangled  into  the  member  name  that  carries 
through  to  the  linker.  All  the  protection  checking  is  done  by  the 
compiler;  it  has  vanished  by  runtime. 

Noticethatthe  interface  presented  to  the  client  programmer  is  now 
truly  that  of  a push-down  stack.  It  happens  to  be  implemented  as  a 
linked  list,  but  you  can  changethat  without  affecting  what  the 
client  programmer  interacts  with,  or  (more  importantly)  a single 
lineof  client  code. 


Handle  classes 

A ccess  control  i n C -H-  al  I ows  you  to  separate  i nterface  from 
implementation,  but  the  implementation  hiding  is  only  partial.  The 
compiler  must  still  see  the  declarations  for  all  parts  of  an  object  in 
order  to  create  and  manipulate  it  properly.  You  could  imaginea 
programming  language  that  requires  only  the  public  i nterface  of  an 
object  and  allowsthe  private  implementation  to  be  hidden,  butC-H- 
performs  type  checking  statically  (at  compile  time)  as  much  as 
possible.  This  means  that  you'll  learn  as  early  as  possible  if  there's 
an  error.  It  also  means  that  your  program  is  more  efficient. 

However,  including  the  private  implementation  has  two  effects:  the 
implementation  is  visibleeven  if  you  can't  easily  access  it,  and  it 
can  cause  needless  recompilation. 
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Hiding  the  impiementation 

Some  projects  cannot  afford  to  have  their  implementation  visible  to 
the  client  programmer.  It  may  show  strategic  information  in  a 
library  header  file  that  the  company  doesn't  want  avail  able  to 
competitors.  You  may  be  working  on  a system  where  security  is  an 
issue  - an  encryption  algorithm,  for  example  - and  you  don't  want 
to  expose  any  clues  in  a header  file  that  might  help  people  to  crack 
the  code.  Or  you  may  be  putting  your  library  in  a "hostile" 
environment,  wherethe  programmers  will  directly  access  the 
private  components  anyway,  using  pointers  and  casting.  In  all 
these  situations,  it's  valuable  to  have  the  actual  structure  compiled 
inside  an  implementation  file  rather  than  exposed  in  a header  file. 

Reducing  recompilation 

The  project  manager  in  your  programming  environment  will  cause 
a recompilation  of  a file  if  that  file  is  touched  (that  is,  modified)  or  if 
another  file  it's  dependent  upon  - that  is,  an  included  header  file - 
is  touched.  This  means  that  any  time  you  make  a change  to  a class, 
whether  it'sto  the  public  interface  or  to  the  private  member 
declarations,  you'll  force  a recompilation  of  anything  that  includes 
that  header  fi  I e.  Thi  s i s often  referred  to  as  the  fragile  based  ass 
problem.  For  a large  project  in  its  early  stages  this  can  be  very 
unwieldy  because  the  underlying  implementation  may  change 
often;  if  the  project  is  very  big,  the  time  for  compiles  can  prohibit 
rapid  turnaround. 

The  techni  que  to  sol  ve  thi  s i s someti  mes  cal  I ed  handle  classes  or  the 
"Cheshirecat"2-  everything  about  the  implementation  disappears 
except  for  a si  ngl  e poi  nter,  the  "smi  I e."  The  poi  nter  refers  to  a 
structure  whose  definition  is  in  the  implementation  file  along  with 
al  I the  member  fu  ncti  on  defi  ni ti  ons.  Thus,  as  I ong  as  the  i nterface  i s 


2 This  name  is  attributed  to  John  Carolan,  one  of  the  early  pioneers  in  C++,  and  of 
course,  Lewis  Carroll.  This  technique  can  also  be  seen  as  a form  of  the  "bridge" 
design  pattern,  described  in  Volume  2. 
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unchanged,  the  header  file  is  untouched.  The  implennentation  can 
change  at  will,  and  only  the  implennentation  fileneedsto  be 
recompiled  and  relinked  with  the  project. 

H ere's  a si  mple  example  demonstrati  ng  the  technique.  The  header 
file  contains  only  the  public  interface  and  a single  pointer  of  an 
incompletely  specified  class: 

//:  C05:Handle.h 
//  Handle  classes 
#lfndef  HANDLE_H 
#define  HANDLE_H 

class  Handle  { 

struct  Cheshire;  //  Class  declaration  only 
Cheshire*  smile; 
public : 

void  initialize ()  ; 
void  cleanup ( ) ; 
int  read ( ) ; 
void  change (int); 

}; 

#endif  //  HANDLE_H  ///:- 

This  is  all  the  cl  lent  programmer  isabletosee.  Theline 

struct  Cheshire; 

is  an  incomplete  type  specification  or  a class  declaration  (A  class 
definition  includesthe  body  of  the  class.)  It  tel  Is  the  compiler  that 
C heshi  reis  a structure  name,  but  it  doesn't  give  any  detai  Is  about 
the  struct  This  is  only  enough  information  to  create  a pointer  to  the 
struct  you  can't  create  an  object  until  the  structure  body  has  been 
provided.  In  thistechnique,  that  structure  body  is  hidden  away  in 
the  i mpl  ementati  on  fi  I e: 

//:  COS : Handle . cpp  {0} 

//  Handle  implementation 
#include  "Handle. h" 

#include  ".. /require . h" 

//  Define  Handle's  implementation: 
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struct  Handle :: Cheshire  { 
int  i ; 

}; 


void  Handle :: initialize  ( ) { 

smile  = new  Cheshire; 
smile->i  = 0; 

} 

void  Handle :: cleanup ( ) { 

delete  smile; 

} 

int  Handle :: read ( ) { 

return  smile->i; 

} 


void  Handle :: change  ( int  x)  { 
smile->i  = x; 

} ///:- 

Cheshireis  a nested  structure,  so  it  must  be  defined  with  scope 
resolution: 

struct  Handle :: Cheshire  { 

In  Handle::initialize(,)stordge  is  allocated  for  a Cheshire 

structure,  and  in  Handle::cleanup(  this  storage  is  released.  This 
storage  is  used  in  lieu  of  all  the  data  elements  you'd  normally  put 
intotheprivatesection  of  the  class.  When  you  compile  Handlexpp 
this  structure  definition  ishidden  away  in  the  object  file  where  no 
one  can  see  it.  If  you  changetheelementsof  Cheshire  the  only  file 
that  must  be  recompiled  isHandiexppbecause  the  header  fileis 
untouched. 

Theuseof  Handieis  liketheuseof  any  class:  include  the  header, 
create  objects,  and  send  messages. 

//:  COS : UseHandle . cpp 
//{L}  Handle 
//  Use  the  Handle  class 
#include  "Handle. h" 
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int  main  ( ) { 

Handle  u; 
u. initialize  () ; 
u . read ( ) ; 
u . change ( 1 ) ; 
u . cleanup ( ) ; 

} ///:- 

The  only  thi  ng  the  cl  lent  programmer  can  access  is  the  pubi  ic 
interface,  so  as  long  as  the  implementation  is  the  only  thing  that 
changes,  the  file  above  never  needs  recompilation.  Thus,  although 
this  isn't  perfect  implementation  hiding,  it's  a big  improvement. 


Summary 

Access  control  in  C++gives  valuable  control  to  the  creator  of  a 
class.  The  users  of  the  class  can  clearly  see  exactly  what  they  can 
use  and  what  to  ignore.  M ore  i mportant,  though,  is  the  ability  to 
ensure  that  no  client  programmer  becomes  dependent  on  any  part 
of  the  underlying  implementation  of  a class.  If  you  know  this  as  the 
creator  of  the  class,  you  can  change  the  underlying  implementation 
with  the  knowledge  that  no  client  programmer  will  be  affected  by 
the  changes  because  they  can't  access  that  part  of  the  class. 

When  you  have  the  ability  to  change  the  underlying 
implementation,  you  can  not  only  improve  your  design  at  some 
later  time,  but  you  also  have  the  freedom  to  make  mistakes.  No 
matter  how  carefully  you  plan  and  design,  you'll  make  mistakes. 
Knowing  that  it's  relatively  safe  to  make  these  mistakes  means 
you'll  be  more  experimental,  you'll  learn  faster,  and  you'll  finish 
your  project  sooner. 

The  pu  bl  I c I nterface  to  a cl  ass  I s w hat  the  cl  I ent  programmer  does 
see,  so  that  I s the  most  I mportant  part  of  the  cl  ass  to  get " ri  ght" 
during  analysis  and  design.  But  even  thatallowsyou  some  leeway 
for  change.  If  you  don't  get  the  I nterface  right  the  first  time,  you  can 
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add  more  functions,  as  long  as  you  don't  removeany  that  client 
programmers  have  already  used  in  their  code. 


Exercises 

Solutions  to  selected  exercises  can  be  found  in  the  electronic  document  TheThinking  in  C++ Annotated 
Solution  Guide,  aval  I able  for  a small  feefromwww.BruceEckel.com. 

1.  Create  a cl  ass  with  public  private  and  protecteddata 
members  and  function  members.  Create  an  object  of  this 
class  and  see  what  kind  of  compiler  messages  you  get 
when  you  try  to  access  all  the  cl  ass  members. 

2.  Writeastructcalled  Libthatcontainsthreestringobjects 
a,  b,and  c.  In  main(  )create  a Lib  object  cal  led  x and 
assign  to  x.a  x.b,  and  x.c  Print  out  the  values.  Now 
replace  a,  b,  and  c with  an  array  of  string  s[3]  Show  that 
your  code  in  main(  )breaksasa  result  of  the  change. 

Now  create  a cl  ass  cal  led  Libc  with  privatestring 
objects  a,  b,  and  c,  and  member  functions  seta( ) geta( ) 
setb( ) getb( ) setc( ) and  getc(  )to  set  and  get  the 
values.  Write  main(  )as  before.  Now  change  the  private 
string  objects  a,  b,  and  c to  a privatearray  of  string  s[3] 
Show  that  the  code  in  main(  )does  not  break  as  a result 
of  the  change. 

3.  Create  a class  and  a global  friendfunction  that 
manipulates  the  privatedata  in  the  class. 

4.  Write  two  classes,  each  of  which  has  a member  function 
that  takes  a poi  nter  to  an  object  of  the  other  cl  ass.  C reate 
instances  of  both  objects  in  main(  )and  call  the 
aforementioned  member  function  in  each  class. 

5.  Create  three  cl  asses.  Thefirst  class  contains  privatedata, 
and  grants  friend  ship  to  the  entire  second  class  and  to  a 
member  function  of  the  third  class.  In  main( ) 
demonstrate  that  al  I of  these  work  correctly. 

6.  Create  a Hen  class.  Insidethis,  nest  a Nest  cl  ass.  Inside 
Nest  place  an  Egg  class.  Each  class  should  have  a 
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display(  )member  function.  In  main( ) create  an  instance 
of  each  class  and  call  thedisplay(  Kunction  for  each  one. 

7.  Modify  Exercise  6 so  that  Nestand  Egg  each  contain 
privatedata.  Grant  friendship  to  allow  the  enclosing 
classes  access  to  this  privatedata. 

8.  Create  a class  with  data  members  distributed  among 
numerous  public  private, and  protectedsections.  Add  a 
member  f u ncti  on  show  M ap(  )that  pri  nts  the  names  of 
each  of  these  data  members  and  their  addresses.  If 
possible,  compileand  run  this  program  on  more  than  one 
compiler  and/  or  computer  and/  or  operating  system  to 
see  if  there  are  layout  d ifferences  i n the  object. 

9.  Copy  the  implementation  and  test  files  for  Stash  in 
Chapter  4 so  that  you  can  compileand  test  Stash .h in  this 
chapter. 

10.  PI  ace  objects  of  the  H en  cl  ass  from  Exerd  se  6 i n a Stash. 
Fetch  them  out  and  pri  nt  them  (if  you  have  not  al  ready 
done  so,  you  will  need  to  add  Hen::print( ). 

11.  Copy  the  implementation  and  test  files  for  Stack  in 

C hapter  4 so  that  you  can  compi  I e and  test  Stack2.h  i n 
this  chapter. 

12.  PI  ace  objects  of  the  H en  cl  ass  from  Exerd  se  6 i n a Stack 
Fetch  them  out  and  pri  nt  them  (if  you  have  not  al  ready 
done  so,  you  will  need  to  add  Hen::print( ). 

13.  Modify  Cheshire!  n Handle.cpp  and  verify  that  your 
project  manager  recompiles  and  relinks  only  thisfile,  but 
doesn't  recompile UseH andle.cpp 

14.  C reate  a StackOf  Intel  ass  (a  stack  that  holds!  nts)  using 
the  "Cheshire  cat"  techniquethat  hides  the  low-level  data 
structure  you  useto  store  the  elements  in  a class  cal  led 
Stackimp  I mplement  two  versions  of  Stackimp  one 
that  uses  a fixed-length  array  of  int  and  one  that  uses  a 
vector<int>Flavea  preset  maximum  size  for  the  stack  so 
you  don't  haveto  worry  about  expanding  the  array  in 
the  fi  rst  version.  N ote  that  the  StackOf  I nt.hclass  doesn't 
haveto  changewith  Stackimp 
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6:  Initialization 
& Cleanup 

Chapter  4 made  a significant  improvement  in  library 
use  by  taking  all  the  scattered  components  of  a typical 
C library  and  encapsulating  them  into  a structure  (an 
abstract  data  type,  called  a c/ass  from  now  on). 
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Thisnotonly  provides  a single  unified  point  of  entry  intoa  library 
component,  but  it  also  hides  the  names  of  thefunctionswithin  the 
class  name.  In  Chapter  5,  access  control  (implementation  hiding) 
was  introduced.  This  gives  the  cl  ass  designer  a way  to  establish 
clear  boundari es  for  determi  ni  ng  what  the  cl  i ent  programmer  is 
allowed  to  manipulate  and  what  isoff  limits.  It  means  the  i nternal 
mechanismsof  a data  type's  operation  are  under  the  control  and 
discretion  of  the  class  designer,  and  it's  clear  to  client  programmers 
what  members  they  can  and  should  pay  attention  to. 

Together,  encapsulation  and  access  control  make  a significant  step 
in  improving  theeaseof  library  use.  The  concept  of  "new  data 
type"  they  provide  is  better  in  some  ways  than  the  existing  built-in 
data  ty  pes  from  C.  The  C-H- compiler  can  now  provide  type- 
checking guarantees  for  that  data  type  and  thus  ensure  a level  of 
safety  when  that  data  type  is  being  used. 

When  it  comes  to  safety,  however,  there's  a lot  more  the  compiler 
can  do  for  us  than  C provides.  In  this  and  future  chapters,  you'll 
see  additional  features  that  have  been  engineered  into  C-H- that 
makethebugsin  your  program  almost  leap  out  and  grab  you, 
sometimes  before  you  even  compile  the  program,  but  usually  in  the 
form  of  compiler  warnings  and  errors.  For  this  reason,  you  will 
soon  get  used  to  the  unlikely-sounding  scenariothat  a C-H- 
program  that  compi  I es  often  ru  ns  ri  ght  the  f i rst  ti  me. 

Two  of  these  safety  issues  are  initialization  and  cleanup.  A large 
segment  of  C bugs  occur  when  the  programmer  forgets  to  initialize 
or  clean  up  a variable.  Thisisespeciallytruewith  C libraries,  when 
client  programmers  don't  know  how  to  initialize  a struct  or  even 
that  they  must.  (Libraries  often  do  not  include  an  initialization 
function,  so  the  client  programmer  isforced  to  initialize  the  struct 
by  hand.)  Cleanup  is  a special  problem  because  C programmers  are 
comfortable  with  forgetting  about  variables  once  they  are  finished, 
so  any  cleaning  up  that  may  be  necessary  for  a I ibrary's  structis 
often  missed. 
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In  C++,  the  concept  of  initialization  and  cleanup  isessential  for 
easy  library  use  and  to  eliminate  the  many  subtle  bugs  that  occur 
when  the  client  programmer  forgets  to  perform  these  activities. 
This  chapter  examines  the  features  in  C++ that  help  guarantee 
proper  initialization  and  cleanup. 


Guaranteed  initialization  with  the 
constructor 

Both  the  Stash  and  Stack  cl  asses  defined  previously  have  a 
function  called  initialize(  )which  hints  by  its  namethat  it  should 
be  called  before  using  the  object  in  any  other  way.  Unfortunately, 
this  means  the  cl  lent  programmer  must  ensure  proper  initialization. 
Client  programmers  are  prone  to  miss  details  like  initialization  in 
their  headlong  rush  to  make  your  amazing  library  solve  their 
problem.  In  C++,  initialization  is  too  important  to  leave  to  the  client 
programmer.  The  class  designer  can  guarantee  initialization  of 
every  object  by  providing  a special  function  called  the  constructor.  If 
a class  has  a constructor,  the  compiler  automatically  cal  Is  that 
constructor  at  the  point  an  object  iscreated,  before  client 
programmers  can  get  thei  r hands  on  the  object.  The  constructor  cal  I 
isn't  even  an  option  for  the  client  programmer;  it  is  performed  by 
the  compiler  at  the  point  the  object  is  defined. 

The  next  challenge  is  what  to  name  this  function.  There  are  two 
issues.  The  first  isthatany  name  you  use  is  something  that  can 
potentially  clash  with  a name  you  might  liketo  useasa  member  in 
the  cl  ass.  The  second  i s that  because  the  compi  I er  i s responsi  bl  e for 
calling  the  constructor,  it  must  always  know  which  function  to  call. 
The  solution  Stroustrup  chose  seems  the  easiest  and  most  logical: 
the  name  of  the  constructor  is  the  same  as  the  name  of  the  class.  It 
makes  sense  that  such  afunction  will  be  called  automatically  on 
initialization. 

Here's  a simple  cl  ass  with  a constructor: 
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class  X { 
int  i ; 
public : 

X();  //  Constructor 

}; 

Now,  when  an  object  is  defined, 

void  f ( ) { 

X a; 

//  . . . 

} 

the  same  thing  happens  as  if  a were  an  int  storage  is  allocated  for 
the  object.  But  when  the  program  reaches  the  sequence po/nt  (point 
of  execution)  wherea  isdefined,  the  constructor  iscalled 
automatically.  That  is,  the  compiler  quietly  inserts  the  cal  I toX::X( ) 
for  the  object  a at  the  poi  nt  of  defi  nition.  Li  ke  any  member  function, 
the  first  (secret)  argument  to  the  constructor  is  the  this  pointer  - the 
addressof  the  object  for  which  it  is  being  called.  I n the  case  of  the 
constructor,  however,  thisis  pointing  to  an  un-initial ized  block  of 
memory,  and  it's  thejob  of  the  constructor  to  initializethis  memory 
properly. 

Like  any  function,  the  constructor  can  have  arguments  to  al  low  you 
to  specify  how  an  object  is  created,  give  it  initialization  values,  and 
so  on.  Constructor  arguments  provideyou  with  a way  to  guarantee 
that  all  partsof  your  object  are  initial  ized  to  appropriate  values.  For 
example,  if  a cl  ass  Tree  has  a constructor  that  takes  a single  integer 
argument  denoting  the  height  of  the  tree,  then  you  must  create  a 
tree  object  I ike  this: 

Tree  t(12);  //  12-foot  tree 

I f T ree(i nt)i s you r only  constructor,  the  compi  I er  won't  I et  you 
create  an  object  any  other  way.  (We'll  look  at  multiple  constructors 
and  different  ways  to  cal  I constructors  i n the  next  chapter.) 

That's  really  all  there  isto  a constructor;  it's  a specially  named 
function  that  iscalled  automatically  by  the  compiler  for  every 


304 


Thinking  in  C+  + 


www.BruceEckel.com 


object  at  the  point  of  that  object's  creation.  Despite  it's  simpiicity,  it 
i s except!  onai  i y vai  uabi  e becau se  i t ei  i nni  nates  a i arge  ci  ass  of 
probiennsand  makes  the  code  easier  to  write  and  read,  in  the 
precedingcodefragment,  forexampie,  you  don't  see  an  expiicit 
function  caii  to  someinitialize(  )function  that  isconceptuaiiy 
separate  from  definition,  in  C++,  definition  and  initiaiization  are 
unified  concepts  - you  can't  have  one  without  the  other. 

Both  the  constructor  and  destructor  are  very  unusuai  types  of 
functions:  they  have  no  return  vaiue.  This  is  distinctiy  different 
from  a void  return  vaiue,  in  which  the  function  returns  nothing  but 
you  stiii  havethe option  to  make  it  something  eise.  Constructors 
and  destructors  return  nothing  and  you  don't  have  an  option.  The 
acts  of  bri  ngi  ng  an  object  i nto  and  out  of  the  program  are  speci  ai , 
iike  birth  and  death,  and  the  compi  ier  ai  ways  makes  the  function 
caiis  itseif,  to  makesurethey  happen,  if  there  were  a return  vaiue, 
and  if  you  couid  seiect  your  own,  the  compi  ierwou id  somehow 
have  to  know  what  to  do  with  the  return  vaiue,  or  thedient 
programmer  wou id  havetoexpiicitiy  caii  constructors  and 
destructors,  which  wouid  ei i mi nate their  safety. 


Guaranteed  cleanup  with  the 
destructor 

As  a C programmer,  you  often  thi  nk  about  the  i mportance  of 
initiaiization,  but  it's  rarer  to  think  about  deanup.  After  aii,  what 
do  you  need  to  do  to  dean  up  an  int?Just  forget  about  it.  However, 
with  iibraries,  just  "ietting  go"  of  an  object  once  you're  done  with  it 
is  not  so  safe.  What  if  it  modifies  some  piece  of  hardware,  or  puts 
something  on  the  screen,  or  aiiocates  storage  on  the  heap?  if  you 
just  forget  about  it,  your  object  never  achieves  dosu re  upon  its  exit 
from  thisworid.  in  C++,  deanup  isasimportant  as  initiaiization 
and  is  therefore  guaranteed  with  the  destructor. 
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The  syntax  for  the  destructor  is  si  mi  lar  to  that  for  the  constructor: 
the  class  name  is  used  for  the  name  of  the  function.  H owever,  the 
destructor  is  distinguished  from  the  constructor  by  a leading  tilde 
(~).  I n addition,  the  destructor  never  has  any  arguments  because 
destruction  never  needs  any  options.  Here's  the  declaration  for  a 
destructor: 

class  Y { 
public : 

~Y()  ; 

}; 

The  destructor  is  cal  led  automatically  by  the  compiler  when  the 
object  goes  out  of  scope.  Y ou  can  see  where  the  constructor  gets 
called  by  the  point  of  definition  oftheobject,  but  the  only  evidence 
for  a destructor  cal  I is  the  closing  braceof  the  scope  that  surrounds 
the  object.  Yet  the  destructor  is  still  called,  even  when  you  use  goto 
to  jump  out  of  a scope,  (goto  still  exists  in  C++for  backward 
compati  bi  I ity  with  C and  for  the  ti  mes  when  it  comes  i n handy.) 
You  should  note  that  a nonlocal  goto,  implemented  by  the  Standard 
C library  functions seljmp(  )and  longjmp( ) doesn't  cause 
destructors  to  be  called.  (This  isthe  specification,  even  if  your 
compiler  doesn't  implement  itthat  way.  Relying  on  afeaturethat 
isn't  in  the  specification  means  your  code  is  nonportable.) 

H ere's  an  example  demonstrati  ng  the  features  of  constructors  and 
destructors  you've  seen  so  far: 

//:  CO  6 : Constructor 1 . cpp 
//  Constructors  & destructors 
#include  <iostreain> 
using  namespace  std; 

class  Tree  { 
int  height; 
public : 

Tree  (int  initialHeight ) ; //  Constructor 

~Tree();  //  Destructor 
void  grow (int  years); 
void  printsizeO; 
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}; 


Tree :: Tree ( int  initialHeight ) { 

height  = initialHeight; 

} 

Tree : : -Tree  ( ) { 

cout  <<  "inside  Tree  destructor"  <<  endl; 
printsize ( ) ; 

} 

void  Tree :: grow ( int  years)  { 
height  +=  years; 

} 

void  Tree :: printsize ( ) { 

cout  <<  "Tree  height  is  " <<  height  <<  endl; 

} 

int  main  ( ) { 

cout  <<  "before  opening  brace"  <<  endl; 

{ 

Tree  t ( 12 ) ; 

cout  <<  "after  Tree  creation"  <<  endl; 
t . printsize ( ) ; 
t . grow ( 4 ) ; 

cout  <<  "before  closing  brace"  <<  endl; 

} 

cout  <<  "after  closing  brace"  <<  endl; 

} ///:- 

H ere's  the  output  of  the  above  program: 

before  opening  brace 
after  Tree  creation 
Tree  height  is  12 
before  closing  brace 
inside  Tree  destructor 
Tree  height  is  16 
after  closing  brace 

You  can  seethat  the  destructor  is  automatically  called  at  the  closing 
brace  of  the  scope  that  end  oses  it. 
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Elimination  of  the  definition  block 

In  C,  you  must  always  define  all  the  variables  at  the  beginning  of  a 
block,  after  the  opening  brace.  This  is  not  an  uncommon 
requirement  in  programming  languages,  and  the  reason  given  has 
often  been  that  it's  "good  programming  style."  On  this  point,  I have 
my  suspicions.  It  has  always  seemed  inconvenient  to  me,  as  a 
programmer,  to  pop  back  to  the  beginning  of  a block  every  time  I 
need  anew  variable.  I also  find  code  more  readable  when  the 
variable  definition  is  close  to  its  point  of  use. 

Perhaps  these  arguments  are  stylistic.  In  C++,  however,  there's  a 
significant  problem  in  being  forced  to  define  all  objects  at  the 
beginning  of  a scope.  If  a constructor  exists,  it  must  be  called  when 
the  object  is  created.  H owever,  if  the  constructor  takes  one  or  more 
initialization  arguments,  how  do  you  know  you  will  have  that 
initialization  information  at  the  beginning  of  ascope?  In  the  general 
programming  situation,  you  won't.  Because C has  no  concept  of 
private  this  separation  of  definition  and  initialization  is  no 
problem.  However,  C++guarantees that  when  an  object  is  created, 
it  is  simultaneously  initialized.  Thisensures  that  you  will  have  no 
uninitialized  objects  running  around  in  your  system.  C doesn't 
care;  infact,C  encourages  this  practice  by  requiring  you  to  define 
variables  at  the  beginning  of  a block  before  you  necessarily  have 
the  initialization  information^. 

In  general,  C++ will  notallow  you  to  create  an  object  before  you 
have  the  initialization  information  for  the  constructor.  Because  of 
this,  the  language  wouldn't  defeasible  if  you  had  to  define 
variables  at  the  beginning  of  a scope.  In  fact,  the  style  of  the 
language  seems  to  encourage  the  defi  nition  of  an  object  as  close  to 
its  point  of  use  as  possible.  In  C++,  any  rule  that  applies  to  an 
"object"  automatically  refers  to  an  objectof  a built-in  type  as  well. 


^ C99,  The  updated  version  of  Standard  C,  allows  variables  to  be  defined  at  any  point 
in  ascope,  like  C++. 
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This  means  that  any  class  object  or  variable  of  a bui  It-i  n type  can 
also  bedefined  at  any  point  in  a scope.  It  also  means  that  you  can 
wait  until  you  have  the  information  for  a variable  before  defining 
it,  so  you  can  always  define  and  initialize  at  the  same  time: 

//:  COG :DefineInitialize . cpp 
//  Defining  variables  anywhere 
#include  /require . h" 

#include  <iostream> 

#include  <string> 
using  namespace  std; 

class  G { 
int  i ; 
public : 

G ( int  ii ) ; 

}; 

G::G(int  ii)  { i = ii;  } 
int  main  ( ) { 

cout  <<  "initialization  value? 

int  retval  = 0; 

cin  >>  retval; 

require (retval  !=  0); 

int  y = retval  + 3; 

G g (y)  ; 

} ///:- 

You  can  seethat  some  code  is  executed,  then  retval  is  defined, 
initialized,  and  used  to  capture  user  input,  and  then  y and  g are 
defined.  C,  on  the  other  hand,  does  not  allow  avariableto  be 
defined  anywhereexcept  at  the  beginning  of  the  scope. 

In  general,  you  should  define  variables  as  close  to  their  point  of  use 
as  possible,  and  always  initializethem  when  they  aredefined.  (This 
is  a stylistic  suggestion  for  built-in  types,  where  initialization  is 
optional.)  This  is  a safety  issue.  By  reducing  the  duration  of  the 
variabi  e's  avai  I abi  I ity  withi  n the  scope,  you  are  reduci  ng  the  chance 
it  will  be  misused  in  some  other  part  of  the  scope.  In  addition, 
readability  is  improved  becausethe  reader  doesn't  have  to  jump 
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back  and  forth  to  the  begi  nni  ng  of  the  scope  to  know  the  type  of  a 
variable. 


for  loops 

In  C++,  you  will  often  seeaforloop  counter  defined  right  inside 
the  for  express!  on: 

for(int  j = 0;  j < 100;  j++)  { 

cout  <<  "j  = " <<  j <<  endl; 

} 

for(int  i = 0;  i < 100;  i++) 

cout  <<  "1  = " <<  i <<  endl; 

The  statennents  above  are  i mportant  special  cases,  which  cause 
confusion  to  new  C++ programmers. 

The  variables  i andj  aredefined  directly  inside  the  for  express!  on 
(which  you  cannot  do  in  C).  They  are  then  availablefor  use  in  the 
for  loop.  It's  a very  convenient  syntax  because  the  context  removes 
all  question  about  the  purpose  of  i andj,  so  you  don't  need  to  use 
such  ungainly  names  as  i_loop_counteifor  clarity. 

H owever,  some  confusion  may  result  if  you  expect  the  I ifeti  mes  of 
the  variables!  andj  to  extend  beyond  the  scope  of  the  for  loop - 
they  do  not2. 

Chapter  3 points  out  that  whileand  switch  statements  also  allow 
the  definition  of  objects  in  their  control  expressions,  although  this 
usage  seems  far  less  important  than  with  the  for  loop. 


^An  earlier  iteration  of  the  C-H- draft  standard  said  the  variable  I ifeti  me  extended  to 
the  end  of  the  scope  that  enclosed  the  for  loop.  Some  compilers  still  implement  that, 
but  i t i s not  correct  so  you  r cod  e w i 1 1 onl  y be  portabi  e i f you  I i mi  t the  scope  to  the  for 
loop. 
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Watch  out  for  local  variables  that  hide  variables  from  the  enclosing 
scope.  I n general , usi  ng  the  same  name  for  a nested  vari  abl  e and  a 
variablethat  is  global  to  that  scope  I sconfusing  and  error  prone^. 

I find  small  scopes  an  indicator  of  good  design.  If  you  have  several 
pages  for  a single  function,  perhaps  you  Ye  trying  to  do  too  much 
with  that  function.  More  granular  functions  are  not  only  more 
useful,  but  it's  also  easier  to  find  bugs. 

Storage  allocation 

A variable  can  now  be  defined  at  any  point  in  a scope,  so  it  might 
seemthatthestoragefor  a vari  able  may  not  be  defined  until  its 
poi  nt  of  defi  niti  on.  I t's  actual  I y more  I i kel y that  the  compi  I er  w i 1 1 
fol  I ow  the  practi  ce  i n C of  al  I ocati  ng  al  I the  storage  for  a scope  at 
the  opening  brace  of  that  scope.  It  doesn't  matter  because,  as  a 
programmer,  you  can't  access  the  storage  (a.k.a.  the  object)  unti  I it 
has  been  defi  ned^.  Although  the  storage  is  allocated  at  the 
beginning  of  the  block,  the  constructor  call  doesn't  happen  until  the 
sequence  point  where  the  object  is  defined  because  the  identifier 
isn't  avail  able  unti  I then.  The  compiler  even  checks  to  makesure 
that  you  don't  put  the  object  definition  (and  thus  the  constructor 
call)  wherethe  sequence  point  only  conditionally  passes  through  it, 
such  as  in  a switch  statement  or  somewhere  a goto  can  jump  past 
it.  U ncommenti  ng  the  statements  i n the  fol  low  i ng  code  will 
generate  a warning  or  an  error: 

//:  CO  6 : No jump . cpp 

//  Can't  jump  past  constructors 

class  X { 
public : 

X()  ; 


^Thejava  language  considers  this  such  a bad  idea  that  it  flags  such  codeasan  error. 
^OK,  you  probably  could  by  fooling  around  with  pointers,  but  you'd  be  very,  very 
bad. 
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}; 


X::X()  {} 

void  f (int  i)  { 
if(i  < 10)  { 

//!  goto  jumpl;  //  Error:  goto  bypasses  init 

} 

X xl;  //  Constructor  called  here 
j ump 1 : 
switch(i)  { 
case  1 : 

X x2;  //  Constructor  called  here 

break; 

//!  case  2 : //  Error:  case  bypasses  init 
X x3;  //  Constructor  called  here 

break; 


} 

int  main  ( ) { 

f (9)  ; 
f (11)  ; 

}///:- 

In  the co(de above,  both  thegotoan(d  theswitchcan  potentially 
jump  pastthesequencepoint  where  a constructor  is  called.  That 
object  will  then  be  in  scope  even  if  the  constructor  hasn't  been 
called,  so  the  compiler  gives  an  error  message.  This  once  again 
guarantees  that  an  object  cannot  be  created  unless  it  is  also 
initialized. 

All  the  storage  allocation  discussed  here  happens,  of  course,  on  the 
stack.  The  storage  i s al  I ocated  by  the  compi  I er  by  movi  ng  the  stack 
pointer  "down"  (a  relativeterm,  which  may  indicate  an  increase  or 
decrease  of  the  actual  stack  pointer  value,  depending  on  your 
machine).  Objects  can  also  be  allocated  on  the  heap  using  new, 
which  is  something  we'll  explore  further  in  Chapter  13. 


312 


Thinking  in  C+  + 


www.BruceEckel.com 


Stash  with  constructors  and 
destructors 

The  exampl es  from  previ  ous  chapters  have  obvi  ous  functi  ons  that 
map  to  constructors  and  destructors:  initialize(  )and  cleanup( ) 

H ere's  the  Stash  header  usi  ng  constructors  and  destructors: 

// : COG : Stash2 . h 

//  With  constructors  & destructors 
#ifndef  STASH2_H 
#define  STASH2_H 

class  Stash  { 

int  size;  //  Size  of  each  space 

int  quantity;  //  Number  of  storage  spaces 
int  next;  //  Next  empty  space 

//  Dynamically  allocated  array  of  bytes: 
unsigned  char*  storage; 
void  inflate (int  increase); 
public : 

Stash (int  size) ; 

-Stash ( ) ; 

int  add (void*  element); 
void*  fetch  (int  index); 
int  count  ( ) ; 

}; 

#endif  //  STASH2_H  ///:- 

The  only  member  functi  on  definitions  that  are  changed  are 
initialize(  land  cleanup( ) which  have  been  replaced  with  a 
constructor  and  destructor: 

//:  CO  6 : Stash2 . cpp  {0} 

//  Constructors  & destructors 
#include  "Stash2.h" 

#include  /require . h" 

#include  <iostream> 

#include  <cassert> 
using  namespace  std; 
const  int  increment  = 100; 

Stash :: Stash ( int  sz)  { 


6:  I nitialization  S(  Cleanup 


313 


size  = sz; 
quantity  = 0; 
storage  = 0; 
next  = 0; 


int  Stash :: add (void*  element)  { 

if (next  >=  quantity)  //  Enough  space  left? 

inflate (increment) ; 

//  Copy  element  into  storage, 

//  starting  at  next  empty  space: 
int  startBytes  = next  * size; 
unsigned  char*  e = (unsigned  char* ) element ; 
for(int  1=0;  i < size;  i++) 
storage [ startBytes  + i]  = e[i]; 
next+t ; 

return (next  - 1);  //  Index  number 


void*  Stash :: fetch ( int  index)  { 

require (0  <=  index,  "Stash :: fetch  (-) index"); 
if (index  >=  next) 

return  0;  //  To  indicate  the  end 
//  Produce  pointer  to  desired  element: 
return  &( storage [ index  * size]); 

} 

int  Stash :: count  ( ) { 

return  next;  //  Number  of  elements  in  CStash 

} 

void  Stash :: inf late ( int  increase)  { 
require ( increase  > 0, 

"Stash :: inf late  zero  or  negative  increase"); 
int  newQuantity  = quantity  + increase; 
int  newBytes  = newQuantity  * size; 
int  oldBytes  = quantity  * size; 

unsigned  char*  b = new  unsigned  char [newBytes ] ; 
for  (int  i = 0;  i < oldBytes;  i++) 

b[i]  = storage [i];  //  Copy  old  to  new 
delete  [] (storage);  //  Old  storage 
storage  = b;  //  Point  to  new  memory 
quantity  = newQuantity; 
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Stash : : -Stash ( ) { 

if (storage  ! = 0 ) { 

cout  <<  "freeing  storage"  <<  endl; 
delete  [] storage; 

} 

} ///:- 

You  can  see  that  the  require.hfunctions  are  being  used  to  watch  for 
programmer  errors,  i nstead  of  assert( ) The  output  of  a fai  led 
assert(  )is  not  as  useful  asthatof  therequire.hfunctions(which 
will  be  shown  later  in  the  book). 

Because  inf  I ate(  )is  private,  the  only  way  a require(  )could  fail  is  if 
one  of  the  other  member  functions  accidentally  passed  an  incorrect 
valueto  inflate! ) If  you  are  certain  thiscan't  happen,  you  could 
consider  removing  the  require! ) but  you  might  keep  in  mind  that 
until  theclassisstable,  there's  always  the  possibility  that  new  code 
might  be  added  to  the  cl  ass  that  could  causeerrors.  Thecostof  the 
require!  )islow  (and  could  be  automatically  removed  using  the 
preprocessor)  and  the  val  ue  of  code  robustness  i s hi  gh. 

Notice  in  thefollowingtest  program  how  the  definitions  for  Stash 
objects  appear  right  before  they  are  needed,  and  how  the 
initialization  appears  as  part  of  the  definition,  in  the  constructor 
argument  list: 

//:  CO  6 : Stash2Test . cpp 
//{L}  Stash2 

//  Constructors  & destructors 
#include  "Stash2.h" 

#include  /require . h" 

#include  <fstream> 

#include  <iostream> 

#include  <string> 
using  namespace  std; 

int  main  ( ) { 

Stash  intStash (sizeof  (int) ) ; 
for(int  i = 0;  i < 100;  i++) 
intStash. add (&i) ; 

for  (int  j = 0;  j < intStash . count () ; j++) 
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cout  <<  " intStash . fetch ( " <<  j <<  ")  = " 

<<  *( int* ) intStash . fetch ( j ) 

<<  endl; 

const  int  bufsize  = 80; 

Stash  stringStash (sizeof (char)  * bufsize); 
ifstream  in ( "Stash2Test . cpp" ) ; 
assure  (in,  " Stash2Test . cpp" ) ; 
string  line; 

while (getline (in,  line)) 

stringStash . add ( (char* ) line . c_str ( ) ) ; 
int  k = 0; 
char*  cp; 

while ( (cp  = (char* ) stringStash . fetch (k++) )! =0 ) 
cout  <<  " stringStash . fetch ( " <<  k <<  ")  = " 

<<  cp  <<  endl; 

} ///:- 

Also  notice  how  thecleanup(  )callshave  been  eliminated,  but  the 
destructors  are  still  automatically  called  when  intStash  and 
stringStashgo  out  of  scope. 

O ne  thi  ng  to  be  aware  of  I n the  Stash  exampi  es:  I 'm  bei  ng  very 
careful  to  use  only  built-in  types;  that  is,  those  without  destructors. 
If  you  were  to  try  to  copy  class  objects  into  the  Stash,  you'd  run 
into  all  kinds  of  problems  and  it  wouldn't  work  right.  The  Standard 
C-H- Library  can  actually  make  correct  copies  of  objects  into  its 
containers,  but  this  is  a rather  messy  and  complicated  process.  In 
thefollowing  Stack  example,  you'll  see  that  pointers  are  used  to 
sidestep  this  issue,  and  in  a later  chapter  the  Stash  will  be 
converted  so  that  it  uses  pointers. 


stack  with  constructors  & 
destructors 

Rei  m p I ementi  ng  the  I i n ked  I i st  ( i n si  d e Stack)  w i th  constru ctors  an d 
destructors  shows  how  neatly  constructors  and  destructors  work 
with  new  and  delete  Here's  the  modified  header  file: 

I // : COG : StackS . h 
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//  With  constructors/destructors 
#ifndef  STACK3_H 
#define  STACK3_H 

class  Stack  { 
struct  Link  { 
void*  data; 

Link*  next; 

Link (void*  dat.  Link*  nxt); 

~Link  ( ) ; 

}*  head; 
public : 

Stack ( ) ; 

-Stack ( ) ; 

void  push (void*  dat); 
void*  peek  ( ) ; 
void*  pop ( ) ; 

}; 

#endif  //  STACK3_H  ///:- 

N ot  only  (does  Stack  have  a construrtor  and  (destrurtor,  but  so  (does 
thenestecJ  class  Link: 

//:  CO  6 : stacks . cpp  {0} 

//  Constructors/destructors 
#include  "Stacks. h" 

#include  /require . h" 
using  namespace  std; 

Stack :: Link :: Link (void*  dat.  Link*  nxt)  { 
data  = dat; 
next  = nxt ; 

} 

Stack :: Link :: -Link  ( ) { } 

Stack :: Stack  ( ) { head  = 0;  } 

void  Stack :: push (void*  dat)  { 
head  = new  Link (dat , head)  ; 

} 

void*  Stack :: peek ( ) { 

require (head  !=  0,  "Stack  empty"); 
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return  head->data; 


} 


void*  Stack: :pop()  { 

if (head  ==  0)  return  0; 
void*  result  = head->data; 

Link*  oldHead  = head; 
head  = head->next; 
delete  oldHead; 
return  result; 

} 

Stack : : -Stack ( ) { 

require (head  ==  0,  "Stack  not  empty"); 

} ///:- 

TheLink::Link(  )constructor  simply  initializes thedataan(d  next 
pointers,  so  in  Stack::push(  )the  line 

head  = new  Link (dat , head) ; 

notonly  allocates  a new  link  (using  dynamic  object  creation  with 
the  keyword  new,  introduced  in  Chapter  4),  but  it  also  neatly 
i niti al  izes  the  poi  nters  for  that  I i nk. 

You  may  wonder  why  the  destructor  for  Link  doesn't  do  anything 
- in  particular,  why  doesn't  itdeletethe  data  poi  nter?There  are 
two  problems.  In  Chapter  4,  where  the  Stack  was  introduced,  it 
was  pointed  out  that  you  cannotproperlydeleteavoidpointer  if  it 
points  to  an  object  (an  assertion  that  will  be  proven  in  Chapter  13). 
But  in  addition,  if  the  Link  destructor  deleted  the  data  pointer, 
pop(  )would  end  up  returning  a pointer  to  a deleted  object,  which 
would  definitely  be  a bug.  This  is  sometimes  referred  to  as  the  issue 
of  ownership:  theLinkand  thus  the  Stack  only  holds  the  pointers, 
but  is  not  responsible  for  cleaning  them  up.  This  means  that  you 
must  be  very  careful  that  you  know  who  is  responsible.  For 
example,  if  you  don't  pop(  )and  deieteall  the  pointers  on  the 
Stack,  they  won't  get  cleaned  up  automatically  by  the  Stack's 
destructor.  This  can  bea  sticky  issueand  leadsto  memory  leaks,  so 
knowing  who  is  responsible  for  cleaning  up  an  object  can  makethe 
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difference  between  a successful  program  and  a buggy  one  - that's 
why  Stack::~Stack(  )Drints  an  error  message  if  the  Stack  object 
isn't  empty  upon  destruction. 

Because  the  allocation  and  cleanup  of  the  Link  objects  are  hidden 
within  Stack-  it's  part  of  the  underlying  implementation  - you 
don't  see  it  happening  in  the  test  program,  although  you  are 
responsible  for  deleting  the  pointers  that  come  back  from  pop( ) 

//:  CO  6 : StackSTest . cpp 
//{L}  stacks 
//{T}  StackSTest . cpp 
//  Constructors/destructors 
#include  "Stacks. h" 

#include  ".. /require . h" 

#include  <fstream> 

#include  <iostream> 

#include  <string> 
using  namespace  std; 

int  main(int  argc,  char*  argv[])  { 

requireArgs (argc,  1);  //  File  name  is  argument 
ifstream  in(argv[l]); 
assure (in,  argv[l]); 

Stack  textlines; 
string  line; 

//  Read  file  and  store  lines  in  the  stack: 
while (getline (in,  line)) 

textlines . push (new  string (line) ) ; 

//  Pop  the  lines  from  the  stack  and  print  them: 
string*  s; 

while((s  = ( string* ) text lines . pop  0 ) !=  0)  { 

cout  <<  *s  <<  endl; 
delete  s; 


} ///:- 

In  this  case,  all  the  lines  in  textiinesare  popped  and  deleted,  but  if 
they  weren't,  you'd  get  a require!  )messagethat  would  mean  there 
was  a memory  leak. 
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Aggregate  initialization 

An  aggregate  is  just  what  it  sounds  like:  a bunch  of  things  dumped 
together.  This  definition  includes  aggregates  of  mixed  types,  like 
struck  and  clas^.  An  array  is  an  aggregateof  a single  type. 

Initializing  aggregates  can  be  error-prone  and  tedious.  C-h- 
aggregate  initialization  makes  it  much  safer.  When  you  create  an 
object  that's  an  aggregate,  all  you  must  do  is  make  an  assignment, 
and  the  initialization  will  betaken  care  of  by  the  compiler.  This 
assignment  comes  in  several  flavors,  depending  on  the  type  of 
aggregate  you're  dealing  with,  but  in  all  cases  the  elements  in  the 
assignment  must  be  surrounded  by  curly  braces.  For  an  array  of 
bui  It-i  n types  this  is  quite  si  mple: 

I int  a[5]  = { 1,  2,  3,  4,  5 }; 

If  you  try  to  give  more  initial  izers  than  there  are  array  elements,  the 
compiler  gives  an  error  message.  But  what  happens  if  you  give 
fewer  initializers?  For  example: 

I int  b [ 6 ] = { 0 } ; 

H ere,  the  compi  I er  w i 1 1 use  the  f i rst  i ni  ti  al  i zer  for  the  f i rst  array 
dement,  and  then  use  zero  for  all  the  elements  without  initializers. 
Notice  this  initialization  behavior  doesn't  occur  if  you  define  an 
array  without  a list  of  initializers.  So  the  expression  above  is  a 
succinct  way  to  initialize  an  array  to  zero,  without  using  aforloop, 
and  without  any  possibility  of  an  off-by-one  error  (Depending  on 
the  compiler,  it  may  also  be  more  efficient  than  theforloop.) 

A second  shorthand  for  arrays  is  automatic  counting,  in  which  you 
letthecompiler  determine  the  size  of  the  array  based  on  the 
number  of  initializers: 

I int  c[]  = { 1,  2,  3,  4 }; 

Now  if  you  decideto  add  another  element  to  the  array,  you  simply 
add  another  initializer.  If  you  can  set  your  code  up  so  it  needs  to  be 
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changed  in  only  one  spot,  you  reducethe  chance  of  errors  during 
modification.  But  how  do  you  determine  the  size  of  the  array?  The 
expression  sizeof  c/  sizeof  *<size  of  the  entire  array  divided  by 
the  size  of  the  first  element)  does  the  trick  in  a way  that  doesn't 
need  to  be  changed  if  the  array  size  changes^: 

for(int  i = 0;  i < sizeof  c / sizeof  *c;  i++) 
c [i] ++; 

Becausestructuresarealsoaggregates,  they  can  beinitialized  in  a 
similar  fashion.  BecauseaC-stylestructhasall  of  its  members 
public  they  can  be  assigned  directly: 

struct  X { 
int  i ; 
float  f; 
char  c; 

}; 


X xl  = { 1,  2.2,  'c'  }; 

If  you  have  an  array  of  such  objects,  you  can  initialize  them  by 
using  a nested  set  of  curly  braces  for  each  object: 

X x2[3]  = { {1,  1.1,  'a' },  {2,  2.2,  'b' } }; 

Here,  the  third  object  is  initialized  to  zero. 

If  any  of  the  data  members  are  private(which  is  typical  ly  the  case 
for  a well-designed  class  in  C++),  or  even  if  everything's  public  but 
there's  a constructor,  thi  ngs  are  different.  I n the  examples  above, 
the  i ni ti  al  i zers  are  assi gned  d i recti y to  the  el ements  of  the 
aggregate,  but  constructors  are  a way  of  ford  ng  i nitial  ization  to 
occur  through  a formal  i nterface.  H ere,  the  constructors  must  be 
called  to  perform  the  initialization.  So  if  you  haveastructthat 
looks  I ike  this. 


5 1 n Volume  2 of  this  book  (freely  available  at  www.BruceEckel.com),  you'll  see  a 
more  succinct  calculation  of  an  array  size  using  templates. 
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struct  Y { 
float  f; 
int  i ; 

Y (int  a) ; 

}; 

You  must  indicate  constructor  cal  Is.  The  best  approach  is  the 
expl  icit  one  as  fol  lows: 

Y yl[]  = { Y(l),  Y(2),  Y(3)  }; 

You  get  three  objects  and  threeconstructor  calls.  Any  time  you 
have  a constructor,  whether  it'sastructwith  all  members  publicor 
aclasswith  privatedata  members,  all  the  initialization  must  go 
through  the  constructor,  even  if  you're  using  aggregate 
initialization. 

H ere's  a second  example  showing  multi  pie  constructor  arguments: 

//:  COG :Multiarg. cpp 
//  Multiple  constructor  arguments 
//  with  aggregate  initialization 
#include  <iostream> 
using  namespace  std; 

class  Z { 
int  i,  j; 
public : 

Z (int  ii,  int  j j ) ; 
void  print  ( ) ; 

}; 


Z::Z(int  ii,  int  jj)  { 
i = ii; 

j = jj; 

} 


void  Z : : print  ( ) { 

cout  <<  " i = " <<  i <<  " , j = " <<  j <<  endl; 

} 

int  main  ( ) { 

Z zz[]  = { Z(l,2),  Z(3,4),  Z(5,6),  Z(7,8)  }; 
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for(int  i = 0;  i < sizeof  zz  / sizeof  *zz;  i++) 
zz [ i ] . print ( ) ; 

} ///:- 

Notice  that  it  looks  like  an  explicit  constructor  is  cal  led  for  each 
object  in  the  array. 


Default  constructors 

A default  constructor  is  one  that  can  be  called  with  no  arguments.  A 
default  constructor  is  used  to  create  a "vanilla  object,"  but  it's  also 
important  when  the  compiler  istold  to  create  an  object  but  isn't 
given  any  details.  For  example,  if  you  take  the  struct  Ydefined 
previously  and  use  it  in  a definition  likethis, 

I Y y2[2]  = { Y(l)  }; 

the  compiler  will  complain  that  it  cannot  find  a default  constructor. 
The  second  object  in  the  array  wants  to  be  created  with  no 
arguments,  and  that's  where  the  compiler  looks  for  a default 
constructor.  I n fact,  if  you  simply  define  an  array  of  Y objects, 

I Y y3[7] ; 

the  compiler  will  complain  because  it  must  havea  default 
constructor  to  initialize  every  object  in  the  array. 

The  same  problem  occurs  if  you  create  an  individual  objectlike 
this: 

I Y y4; 

Remember,  if  you  have  a constructor,  the  compi  ler  ensures  that 
construction  always  happens,  regardless  of  the  situation. 

The  default  constructor  is  so  i mportant  that  /f(and  only  if)  there  are 
no  constructors  for  a structure  (structor  class),  the  compi  ler  will 
automati  cal  I y create  one  for  you . So  thi  s works: 

I //:  CO  6 : AutoDef aultConstructor . cpp 
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//  Automatically-generated  default  constructor 


class  V { 

int  1;  //  private 

};  //No  constructor 

int  main  ( ) { 

V V,  v2  [ 10 ] ; 

} ///:- 

If  any  constructors  are  defi  ned,  however,  and  there's  no  default 
constructor,  the  instances  of  V above  will  generate  compile-time 
errors. 

You  might  think  that  the  compiler-synthesized  constructor  should 
d 0 some  i ntel  I i gent  i ni ti al  i zati on,  I i ke  setti  ng  al  I the  memory  for  the 
object  to  zero.  But  it  doesn't -that  would  add  extra  overhead  but 
be  out  of  the  programmer's  control . If  you  want  the  memory  to  be 
initialized  to  zero,  you  must  do  it  yourself  by  writing  the  default 
constructor  expl  icitly. 

Although  the  compiler  will  create  a default  constructor  for  you,  the 
behavior  of  the  compiler-synthesized  constructor  is  rarely  what 
you  want.  You  should  treat  this  feature  as  a safety  net,  butuseit 
sparingly.  In  general,  you  should  define  your  constructors 
explicitly  and  notallow  the  compiler  to  do  it  for  you. 


Summary 

Theseemingly  elaborate  mechanisms  provided  by  C-H- should  give 
you  a strong  hint  about  the  critical  importance  placed  on 
initialization  and  cleanup  in  the  language.  As  Stroustrup  was 
desi  gni  ng  C -H-,  one  of  the  fi  rst  observati  ons  he  made  about 
productivity  in  C was  that  a significant  portion  of  programming 
problems  are  caused  by  improper  initialization  of  variables.  These 
kindsof  bugs  are  hard  to  find,  and  similar  issues  apply  to  improper 
cleanup.  Because  constructors  and  destructors  allow  you  to 
guarantee  proper  initialization  and  cleanup  (the compiler  will  not 
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allow  an  object  to  be  created  and  destroyed  without  the  proper 
constructor  and  destructor  calls),  you  get  complete  control  and 
safety. 

Aggregate  initialization  is  included  in  asimilar  vein  - it  prevents 
you  from  making  typical  initialization  mistakes  with  aggregates  of 
built-in  types  and  makes  your  code  more  sued  net. 

Safety  during  coding  is  a big  issue  in  C-H-.  Initialization  and 
cleanup  are  an  important  part  of  this,  but  you'll  also  see  other 
safety  issues  as  the  book  progresses. 


Exercises 

Solutions  to  selected  exercises  can  be  found  in  the  electronic  document  TheThinking  in  C++ Annotated 
Solution  Guide,  aval  I able  for  a small  feefromwww.BruceEckel.com. 

1.  Write  a simple  class  cal  led  Simplewith  a constructor  that 
prints  something  to  tell  you  that  it's  been  called.  In 
main(  )makean  objectof  your  class. 

2.  Add  a destructor  to  Exercisel  that  prints  out  a message 
to  tel  I you  that  it's  been  cal  led. 

3 . M od  ify  Exerci  se  2 so  that  the  cl  ass  contai  ns  an  i nt 
member.  M od  ify  the  constructor  so  that  it  takes  an  i nt 
argument  that  it  stores  i n the  class  member.  Both  the 
constructor  and  destructor  should  pri  nt  out  the  int value 
as  part  of  their  message,  so  you  can  seethe  objects  as 
they  are  created  and  destroyed. 

4.  Demonstrate  that  destructors  are  still  called  even  when 
goto  is  used  to  jump  outof  a loop. 

5.  Write  two  for  loops  that  printout  values  from  zero  to  10. 
In  thefirst,  define  the  loop  counter  before  the  for  loop, 
and  in  the  second,  define  the  loop  counter  in  the  control 
expression  of  the  for  loop.  For  the  second  part  of  this 
exerci  se,  mod  ify  the  i dentif i er  i n the  second  for  I oop  so 
that  it  as  the  same  name  as  the  I oop  counter  for  the  first 
and  see  what  your  compiler  does. 
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6.  Modify  the  Handle.^  Handlexpp  and  UseHandlexpp 

fi  les  at  the  end  of  Chapter  5 to  use  constructors  and 
destructors. 

7.  Useaggregate  initialization  to  createan  array  of  double 
in  which  you  specify  the  size  of  the  array  but  do  not 
provide  enough  elements.  Print  out  this  array  using 
sizeof  to  determi  nethe  size  of  the  array.  N ow  create  an 
array  of  doubleusing  aggregate  initialization  and 
automatic  count!  ng.  Print  out  the  array. 

8.  Useaggregate  initialization  to  createan  array  of  string 
objects.  Create  a Stack  to  hold  these  string  and  step 
through  your  array,  pushing  each  stringon  your  Stack 
Finally,  popthestrln^  off  your  Stack  and  print  each 
one. 

9.  Demonstrate  automatic  counting  and  aggregate 
initialization  with  an  array  of  objects  of  the  cl  ass  you 
created  in  Exercise  3.  Adda  member  function  to  that 
class  that  pri  nts  a message.  Calculatethe  size  of  the  array 
and  movethrough  it,  calling  your  new  member  function. 

10.  Create  a class  without  any  constructors,  and  show  that 
you  can  create  objects  with  the  default  constructor.  Now 
create  a nondefault  constructor  (one  with  an  argument) 
for  the  class,  and  try  compiling  again.  Explain  what 
happened. 
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7:  Function  Overloading  & 
Default  Arguments 

One  of  the  important  features  in  any  programming 
language  is  the  convenient  use  of  names. 
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When  you  create  an  object  (a  variable),  you  give  a name  to  a region 
of  storage.  A function  is  a name  for  an  action.  By  making  up  names 
to  descri  be  the  system  at  hand,  you  create  a program  that  is  easier 
for  peopleto  understand  and  change.  It's  a lot  like  writing  prose- 
thegoal  is  to  communicate  with  your  readers. 

A problem  arises  when  mapping  the  concept  of  nuance  in  human 
language  onto  a programming  language.  Often,  the  same  word 
expresses  a number  of  different  meanings,  depending  on  context. 
That  is,  a single  word  has  multiple  meanings-  it's  oi/er/oacfed.  This 
isvery  useful,  especially  when  it  comes  to  trivial  differences.  You 
say  "wash  the  shirt,  wash  the  car."  It  would  be  silly  to  be  forced  to 
say,  "shirt_wash  the  shirt,  car_wash  the  car"  just  so  the  I istener 
doesn't  have  to  make  any  distinction  about  the  action  performed. 
Human  languages  have  built-in  redundancy,  so  even  if  you  miss  a 
few  words,  you  can  still  determine  the  meaning.  We  don't  need 
unique  identifiers-  we  can  deduce  meaning  from  context. 

Most  programming  languages,  however,  require  that  you  havea 
unique  identifier  for  each  function.  If  you  havethree  different  types 
of  data  that  you  want  to  print:  int;  char,  and  float  you  generally 
have  to  create  three  different  function  names,  for  example, 

print_int(  )print_char(  )and  print_float(  )This  loads  extra  work 
on  you  as  you  write  the  program,  and  on  readers  as  they  try  to 
understand  it. 

In  C-H-,  another  factor  forces  the  overloading  of  function  names: 
the  constructor.  Because  the  constructor's  name  i s predetermi  ned 
by  the  name  of  the  cl  ass,  it  would  seem  that  there  can  be  only  one 
constructor.  But  what  if  you  want  to  create  an  object  in  more  than 
oneway?  For  example,  suppose  you  build  a class  that  can  initialize 
itself  in  a standard  way  and  also  by  reading  information  from  a file. 
You  need  two  constructors,  one  that  takes  no  arguments  (the 
default  constructor)  and  one  that  takes  a stringas  an  argument, 
which  is  the  name  of  the  file  to  initialize  the  object.  Both  are 
constructors,  so  they  must  have  the  same  name:  the  name  of  the 
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class.  Thus,  function  overloading  is  essential  to  allow  the  same 
function  name-  the  constructor  in  thiscase-  to  be  used  with 
different  argument  types. 

Although  function  overloading  is  a must  for  constructors,  it's  a 
general  convenience  and  can  be  used  with  any  function,  not  just 
class  member  functions.  In  addition,  function  overloading  means 
that  if  you  have  two  I i brari  es  that  contai  n fu  ncti  ons  of  the  same 
name,  they  won't  conflict  as  long  as  the  argument  lists  are  different. 
We'll  look  at  all  these  factors  in  detail  throughout  this  chapter. 

The  theme  of  this  chapter  is  convenient  use  of  function  names. 
Function  overloading  allowsyou  to  use  the  same  name  for  different 
functions,  but  there's  a second  way  to  make  cal  ling  a function  more 
convenient.  What  if  you'd  liketocall  the  same  function  in  different 
ways?  When  functions  have  long  argument  lists,  it  can  become 
tediousto  write  (and  confusing  to  read)  thefunction  cal  Is  when 
most  of  the  arguments  are  the  same  for  all  the  cal  Is.  A commonly 
used  feature  in  C++ is  cal  led  default  arguments.  A default  argument 
is  one  the  compiler  inserts  if  it  isn't  specified  in  thefunction  call. 
Thus,  thecallsf("hello")f("hi",  1) and  f("howdy",  2,  'c'tan  all 
be  cal  I s to  the  same  f u ncti  on . They  cou  I d al  so  be  cal  I s to  three 
overloaded  functions,  but  when  the  argument  lists  are  this  similar, 
you'l  I usual  I y want  si  mi  I ar  behavi  or,  w hi  ch  cal  I s for  a si  ngl  e 
function. 

Function  overloading  and  default  arguments  really  aren't  very 
complicated.  By  the  time  you  reach  theend  of  this  chapter,  you'll 
understand  when  to  use  them  and  theunderlying  mechanisms  that 
implement  them  during  compiling  and  linking. 


More  name  decoration 

In  Chapter  4,  the  concept  of  name  decoration  was  introduced.  In  the 
code 

I void  f ( ) ; 
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class  X { void  f();  }; 


thefunction  f(  )insidethescopeof  class  Xdoes  not  clash  with  the 
global  version  of  f( ).  The  compiler  performs  this  scoping  by 
manufacturing  different  internal  names  for  the  global  version  of  f( ) 
andX::f( ) In  Chapter  4,  it  was  suggested  that  the  names  are  simply 
the  cl  ass  name  "decorated"  together  with  thefunction  name,  so  the 
internal  names  the  compiler  uses  might  be_f  and_X_f.  However,  it 
turns  out  that  function  name  decoration  involves  more  than  the 
class  name. 

Here's  why.  Suppose  you  want  to  overload  two  function  names 

void  print (char) ; 
void  print ( float ) ; 

It  doesn't  matter  whether  they  are  both  i nside  a class  or  at  the 
global  scope.  The  compiler  can't  generate  unique  internal 
identifiers  if  it  usesonly  the  scope  of  thefunction  names.  You'd  end 
up  with  _printin  both  cases.  The  idea  of  an  overloaded  function  is 
that  you  use  the  same  function  name,  but  different  argument  lists. 
Thus,  for  overloading  to  work  the  compiler  must  decorate  the 
function  name  with  the  names  of  the  argument  types.  The  functions 
above,  defined  at  global  scope,  produce  internal  names  that  might 
look  something  like_print_charand  _print_floatlt's  worth  noting 
there  is  no  standard  for  the  way  names  must  be  decorated  by  the 
compiler,  so  you  will  see  very  different  results  from  one  compiler 
to  another.  (You  can  see  what  it  looks  I ike  by  telling  the  compiler  to 
generate  assembly-language  output.)  This,  of  course,  causes 
problems  if  you  want  to  buy  compiled  libraries  for  a particular 
compiler  and  linker  - but  even  if  name  decoration  were 
standardized,  there  would  be  other  roadblocks  becauseof  the  way 
d ifferent  compi  I ers  generate  code. 

That's  really  all  there  is  to  function  overloading:  you  can  use  the 
same  function  name  for  different  functions  as  long  as  the  argument 
I i sts  are  d ifferent.  The  compi  I er  decorates  the  name,  the  scope,  and 
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the  argument  lists  to  produce  internal  names  for  it  and  the  linker  to 
use. 

Overloading  on  return  values 

It's  common  to  wonder,  "Why  just  scopes  and  argument  lists?  Why 
not  return  values?"  It  seems  at  first  that  it  would  make  sense  to  also 
decorate  the  return  value  with  the  internal  function  name.  Then 
you  could  overload  on  return  values,  as  well: 

void  f ( ) ; 
int  f ( ) ; 

This  works  fine  when  the  compiler  can  unequivocally  determine 
the  mean!  ng  from  the  context,  as  i n i nt  x = f ( );  H owever,  i n C 
you've  always  been  abletocall  a function  and  ignore  the  return 
value(that  is,  you  can  call  thefunction  for  its  s/de  effects).  How  can 
the  compiler  distinguish  which  call  is  meant  in  this  case?  Possibly 
worse  is  the  difficulty  the  reader  has  in  knowing  which  function 
call  is  meant.  Overloading  solely  on  return  value  is  a bit  too  subtle, 
and  thus  isn't  allowed  in  C++. 

Type-safe  linkage 

There  is  an  added  benefit  to  all  of  this  name  decoration.  A 
particularly  sticky  problem  in  C occurs  when  the  client 
programmer  misdeclares  a function,  or,  worse,  a function  is  called 
without  declaring  itfirst,  and  the  compiler  infers  the  function 
deci  arati  on  from  the  way  i t i s cal  I ed . Someti  mes  th i s f u ncti  on 
declaration  is  correct,  but  when  it  isn't,  it  can  be  a difficult  bug  to 
find. 

Because  all  functions  must  be  declared  before  they  are  used  in  C++, 
the  opportunity  for  this  problem  to  pop  up  is  greatly  diminished. 
The  C++ compiler  refuses  to  declare  a function  automatically  for 
you,  so  it's  likely  that  you  will  include  the  appropriate  header  file. 
However,  if  for  some  reason  you  still  manage  to  misdeclarea 
function,  either  by  declaring  by  hand  or  including  the  wrong 
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header  fi  le  (perhaps  one  that  is  out  of  date),  the  name  decoration 
provides  a safety  net  that  is  often  referred  to  as  type-safe  linkage. 

Consider  the  following  scenario.  In  onefile  is  the  definition  for  a 
function: 


//:  C07:Def.cpp  {0} 

//  Function  definition 
void  f ( int ) { } 

///:- 

In  the  second  file,  the  function  ismisdeclared  and  then  called: 

// : C07 : Use . cpp 
//{L}  Def 

//  Function  misdeclaration 
void  f (char) ; 

int  main  ( ) { 

//!  f(l);  //  Causes  a linker  error 

} ///:- 

Even  though  you  can  see  that  the  function  isactuallyf  (inti  the 
compiler  doesn't  know  this  because  it  was  told  - through  an 
explicit  declaration  - that  the  function  is  f (char)  Thus,  the 
compilation  is  successful.  In  C,  the  I inker  would  also  be  successful, 
but  not  in  C++.  Becausethe  compiler  decorates  the  names,  the 
definition  becomes  something  likef_int  whereas  the  use  of  the 
function  isf_char.  When  the  I inker  tries  to  resolve  the  reference  to 
f_char,  it  can  only  find  f_int  and  it  gives  you  an  error  message. 
This  is  type-safe  linkage.  Although  the  problem  doesn't  occur  all 
that  often,  when  it  does  it  can  be  i ncredibly  difficult  to  find, 
especially  in  a large  project.  This  is  one  of  the  cases  where  you  can 
easily  find  a difficult  error  in  aC  program  simply  by  running  it 
through  the  C -H-  compi  I er. 
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Overloading  example 

Wecan  now  modify  earlier  ©camples  to  use  function  overloading. 
As  stated  before,  an  immediately  useful  pi  ace  for  overloading  is  in 
constructors.  You  can  seethis  in  thefol  lowing  version  of  the  Stash 
class: 

// : C07 : Stash3 . h 
//  Function  overloading 
#ifndef  STASH3_H 
#define  STASH3_H 

class  Stash  { 

int  size;  //  Size  of  each  space 

int  quantity;  //  Number  of  storage  spaces 
int  next;  //  Next  empty  space 

//  Dynamically  allocated  array  of  bytes: 
unsigned  char*  storage; 
void  inflate  (int  increase); 
public : 

Stash  (int  size);  //  Zero  quantity 
Stash (int  size,  int  initQuantity) ; 

-Stash ( ) ; 

int  add (void*  element); 
void*  fetch (int  index); 
int  count  ( ) ; 

}; 

#endif  //  STASH3_H  ///:- 

The  first  Stash(  Constructor  is  the  same  as  before,  but  the  second 
one  has  a Quantity  argument  to  indicate  the  initial  number  of 
storage  pi  aces  to  be  allocated.  In  the  definition,  you  can  see  that  the 
internal  val  ue  of  quantity!  s set  to  zero,  along  with  the  storage 
pointer.  In  the  second  constructor,  the  call  to  infiate(initQuantity) 
increasesquantityto  the  allocated  size: 

//:  C07 : Stash3 . cpp  {0} 

//  Function  overloading 
#include  "Stash3.h" 

#include  ".. /require . h" 

#include  <iostream> 

#include  <cassert> 
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using  namespace  std; 

const  int  increment  = 100; 

Stash :: Stash ( int  sz)  { 
size  = sz; 
quantity  = 0; 
next  = 0; 
storage  = 0; 

} 

Stash :: Stash ( int  sz,  int  initQuantity)  { 
size  = sz; 
quantity  = 0; 
next  = 0; 
storage  = 0; 
inflate (initQuantity) ; 

} 

Stash : : -Stash ( ) { 

if (storage  ! = 0 ) { 

cout  <<  "freeing  storage"  <<  endl; 
delete  [] storage; 


int  Stash :: add (void*  element)  { 

if (next  >=  quantity)  //  Enough  space  left? 

inflate (increment)  ; 

//  Copy  element  into  storage, 

//  starting  at  next  empty  space: 
int  startBytes  = next  * size; 
unsigned  char*  e = (unsigned  char* ) element ; 
for(int  i = 0;  i < size;  i++) 
storage [ startBytes  + i]  = e[i]; 
next+f ; 

return (next  - 1);  //  Index  number 


void*  Stash :: fetch ( int  index)  { 

require (0  <=  index,  "Stash :: fetch  (-) index"); 
if (index  >=  next) 

return  0;  //  To  indicate  the  end 
//  Produce  pointer  to  desired  element: 
return  &( storage [ index  * size]); 
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int  Stash :: count  ( ) { 

return  next;  //  Number  of  elements  in  CStash 

} 

void  Stash :: inf late  ( int  increase)  { 
assert (increase  >=  0); 
if (increase  ==  0)  return; 
int  newQuantity  = quantity  + increase; 
int  newBytes  = newQuantity  * size; 
int  oldBytes  = quantity  * size; 

unsigned  char*  b = new  unsigned  char [newBytes ] ; 
for  (int  i = 0;  i < oldBytes;  i++) 

b[i]  = storage [i];  //  Copy  old  to  new 
delete  [] (storage);  //  Release  old  storage 
storage  = b;  //  Point  to  new  memory 
quantity  = newQuantity;  //  Adjust  the  size 
} ///:- 

When  you  usethefirstconstrudor  no  memory  is  allocated  for 
storage  The  allocation  happens  the  first  time  you  try  to  add(  )an 
object  and  any  time  the  current  block  of  memory  is  exceeded  inside 

addO 

Both  constructors  are  exercised  in  the  test  program: 

//:  C07 : StashSTest . cpp 
//{L}  StashS 
//  Function  overloading 
#include  "StashS.h" 

#include  /require . h" 

#include  <fstream> 

#include  <iostream> 

#include  <string> 
using  namespace  std; 

int  main  ( ) { 

Stash  intStash (sizeof  (int) ) ; 
for(int  i = 0;  i < 100;  i++) 
intStash. add (&i) ; 

for  (int  j = 0;  j < intStash . count () ; j++) 

cout  <<  " intStash . fetch ( " <<  j <<  ")  = " 

<<  *( int *) intStash . fetch ( j ) 

<<  endl; 
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const  int  bufsize  = 80; 

Stash  stringStash (sizeof (char)  * bufsize,  100); 
ifstream  in  ( "StashSTest . cpp" ) ; 
assure (in,  "StashSTest . cpp" ) ; 
string  line; 

while (getline (in,  line)) 

stringStash . add ( (char* ) line . c_str ( ) ) ; 
int  k = 0; 
char*  cp; 

while ( (cp  = (char* ) stringStash . fetch (k++) )! =0 ) 
cout  <<  " stringStash . fetch ( " <<  k <<  ")  = " 

<<  cp  <<  endl; 

} ///:- 

The  constructor  call  for  stringStashuses  a second  argument; 
presumably  you  know  something  special  about  the  specific 
problem  you're  solving  that  allows  you  to  choose  an  initial  size  for 

the  Stash. 


unions 

As  you've  seen,  the  only  difference  between  structand  class!  n C++ 
I s th at  stru  ctd  ef au  I ts  to  p u b I i c an d cl  ass  d ef au  I ts  to  p ri  vate  A 
structcan  also  have  constructors  and  destructors,  as  you  might 
expect.  But  it  turns  out  that  a union  can  also  have  a constructor, 
destructor,  member  functions,  and  even  access  control . You  can 
again  seethe  use  and  benefit  of  overloading  in  thefollowing 
example: 

//:  C07 : UnionClass . cpp 

//  Unions  with  constructors  and  member  functions 

#include<iostream> 

using  namespace  std; 

union  U { 

private:  //  Access  control  too! 
int  i ; 
float  f; 
public : 

U (int  a) ; 

U (float  b) ; 
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~U()  ; 

int  read_int ( ) ; 
float  read_f loat ( ) ; 


U : : U ( int  a)  { i = a;  } 

U::U(float  b)  { f = b;  } 

U::~U()  { cout  <<  "U::~U()\n";  } 

int  U : : read_int ( ) { return  i;  } 

float  U : : read_f loat ( ) { return  f;  } 

int  main  ( ) { 

U X (12)  , Y (1 . 9F) ; 

cout  <<  X.read_int()  <<  endl; 

cout  <<  Y . read_f loat ( ) <<  endl; 

} ///:- 

You  might  thi  nk  from  the  code  above  that  the  only  difference 
between  a union  and  aclassistheway  thedata  is  stored  (that  is, 
the  inland  fi  oat  are  overlaid  on  the  same  piece  of  storage). 
However,  a union  cannot  be  used  as  a base  class  during 
inheritance,  which  isquite  limiting  from  an  object-oriented  design 
standpoint  (you'll  learn  about  inheritance  in  Chapter  14). 

A I though  the  member  f u ncti  ons  ci  vi  I i ze  access  to  the  u n i on 
somew hat,  there  i s sti  1 1 no  way  to  prevent  the  cl  i ent  programmer 
from  selecting  the  wrong  element  type  oncethe  union  is  initialized. 
In  the  example  above,  you  could  say  X.read_fioat(  ^en  though  it 
is  inappropriate.  However,  a "safe"  union  can  be  encapsulated  in  a 
class.  In  the  following  example,  notice  how  the  enum  clarifies  the 
code,  and  how  overloading  comes  in  handy  with  the  constructors: 

//:  C07 : SuperVar . cpp 
//  A super-variable 
#include  <iostream> 
using  namespace  std; 

class  SuperVar  { 
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enum  { 

character, 
integer, 
f loating_point 
} vartype;  //  Define  one 
union  { //  Anonymous  union 

char  c; 
int  i ; 
float  f; 

}; 

public : 

SuperVar (char  ch)  ; 
SuperVar(int  ii); 

SuperVar ( float  ff ) ; 
void  print ( ) ; 


SuperVar :: SuperVar (char  ch)  { 
vartype  = character; 
c = ch; 

} 

SuperVar :: SuperVar ( int  ii)  { 
vartype  = integer; 
i = ii; 

} 

SuperVar :: SuperVar ( float  ff)  { 
vartype  = f loating_point ; 
f = ff; 


void  SuperVar :: print  ( ) { 

switch  (vartype)  { 
case  character: 

cout  <<  "character:  " <<  c <<  endl; 

break; 

case  integer: 

cout  <<  "integer:  " <<  i <<  endl; 

break; 

case  f loating_point : 

cout  <<  "float:  " <<  f <<  endl; 
break; 


} 
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int  main  ( ) { 

SuperVar  A ( ' c ' ) , B(12),  C(1.44F); 

A .  print  ( ) ; 

B .  print  ( ) ; 

C .  print  ( ) ; 

} ///:- 

In  the  code  above,  theenum  has  no  type  name  (it  is  an  untagged 
enumeration).  This  is  acceptable  if  you  are  going  to  immediately 
define  instances  of  theenum,  as  is  done  here.  There  is  no  need  to 
refer  to  the  enum'stype  name  in  the  future,  so  the  type  name  is 
optional. 

The  union  has  no  type  name  and  no  variable  name.  This  is  cal  led 
an  anonymous  union,  and  creates  space  for  the  union  but  doesn't 
require  accessing  the  union  elements  with  a variable  name  and  the 
dot  operator.  For  instance,  if  your  anonymous  union  is: 

//:  C07 : AnonymousUnion . cpp 
int  main  ( ) { 

union  { 
int  i ; 
float  f; 

}; 

//  Access  members  without  using  qualifiers: 
i = 12; 
f = 1.22; 

} ///:- 

N otethat  you  access  members  of  an  anonymous  union  just  as  if 
they  were  ordinary  variables.  The  only  difference  is  that  both 
variables  occupy  the  same  space.  If  the  anonymous  union  is  at  fi  le 
scope  (outside  all  functions  and  classes)  then  it  must  be  declared 
staticso  it  has  internal  linkage. 

Although  SuperVaris  now  safe,  its  usefulness  is  a bit  dubious 
because  the  reason  for  using  a union  in  the  first  place  is  to  save 
space,  and  the  addition  of  vartypetakesup  quite  a bit  of  space 
relativeto  the  data  in  theunion,  sothesavings  are  effectively 
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d i mi  nated . There  are  a cou  pi e of  al ternati  ves  to  make  this  scheme 
workable.  If  thevartypecontrolled  more  than  oneunion  instance - 
if  they  were  all  the  same  type- then  you'd  only  need  oneforthe 
group  and  it  wouldn't  take  up  more  space.  A more  useful  approach 
is  to  have  #ifdefs  around  all  thevaitypecode,  which  can  then 
guarantee  things  are  being  used  correctly  during  development  and 
test!  ng.  For  shi  ppi  ng  code,  the  extra  space  and  ti  me  overhead  can 
be  eliminated. 


Default  arguments 

In  Stash3.h  examine  the  two  constructors  for  Stash( ) They  don't 
seem  al  I that  different,  do  they?  I n fact,  the  first  constructor  seems 
to  bea  special  case  of  the  second  one  with  the  initial  sizesetto 
zero.  It's  a bit  of  a waste  of  effort  to  create  and  mai  ntai  n two 
d ifferent  versi  ons  of  a si  mi  I ar  fu  ncti  on . 

C++provides  a remedy  with  default  arguments.  A default  argument 
isa  value  given  in  the  declaration  that  the  compiler  automatically 
inserts  if  you  don't  provide  a value  in  the  function  call.  In  the  Stash 
example,  we  can  replace  the  two  functions: 

Stash (int  size);  //  Zero  quantity 
Stash (int  size,  int  initQuantity) ; 

with  the  single  function: 

I Stash (int  size,  int  initQuantity  = 0); 

TheStash(int)definition  is  simply  removed  - all  that  is  necessary  is 
the  single  Stash(int,  intjdefinition. 

Now,  the  two  object  definitions 

I Stash  A (100) , B (100,  0) ; 

will  produceexactly  the  same  results.  The  identical  constructor  is 
called  in  both  cases,  butfor  A,  the  second  argument  is 
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automatically  substituted  by  the  compiler  when  it  sees  the  first 
argument  is  an  inland  that  there  is  no  second  argument.  The 
compiler  has  seen  the  default  argument,  so  it  knows  it  can  still 
make  the  function  call  if  it  substitutes  this  second  argument,  which 
is  what  you've  told  it  to  do  by  making  it  a default. 

Default  arguments  are  a convenience,  as  function  overloading  isa 
convenience.  Both  features  allow  you  to  use  a singlefunction  name 
in  different  situations.  The  difference  is  that  with  default  arguments 
the  compiler  is  substituting  arguments  when  you  don't  want  to  put 
them  in  yourself.  The  preceding  example  is  a good  pi  ace  to  use 
default  arguments  instead  of  function  overloading;  otherwise  you 
end  up  with  two  or  more  functions  that  have  similar  signatures  and 
similar  behaviors.  If  the  functions  have  very  different  behaviors,  it 
doesn't  usually  make  sense  to  use  default  arguments  (for  that 
matter,  you  might  want  to  question  whether  two  functions  with 
very  different  behaviors  should  have  the  same  name). 

There  are  two  rules  you  must  be  aware  of  when  using  default 
arguments.  First,  only  trailing  arguments  may  be  defaulted.  That  is, 
you  can't  have  a default  argument  followed  by  a non-default 
argument.  Second,  once  you  start  using  default  arguments  in  a 
particular  function  call,  all  the  subsequent  arguments  in  that 
function's  argument  list  must  bedefaulted  (this  follows  from  the 
first  rule). 

Default  arguments  are  only  placed  in  the  declaration  of  a function 
(typically  placed  in  a header  file).  The  compiler  must  seethe 
default  value  before  it  can  use  it.  Sometimes  people  will  place  the 
commented  values  of  the  default  arguments  in  the  function 
definition,  for  documentation  purposes 

void  fn(int  x /*  = 0 */)  { //  ... 
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Placeholder  arguments 

Arguments  in  a function  declaration  can  be  declared  without 
identifiers.  When  these  are  used  with  default  arguments,  it  can  look 
a bit  funny.  You  can  end  up  with 

I void  f(int  x,  int  = 0,  float  = 1.1); 

In  C++ you  don't  need  identifiers  in  the  function  definition,  either: 

I void  f (int  x,  int,  float  fit)  { /*  ...  */  } 

In  the  function  body,  x and  fitcan  dereferenced,  but  not  the 
middle  argument,  because  it  has  no  name.  Function  calls  must  still 
provi de  a val ue  for  the  pi acehol der,  though : f (1)  or  f (1,2, 3-0)  Thi s 
syntax  allows  you  to  put  the  argument  in  as  a placeholder  without 
using  it.  The  idea  is  that  you  might  want  to  change  the  function 
definition  to  use  the  placeholder  later,  without  changing  all  the 
code  where  the  function  is  called.  Of  course,  you  can  accomplish 
the  same  thing  by  using  a named  argument,  but  if  you  define  the 
argument  for  the  function  body  without  using  it,  most  compilers 
will  give  you  a warning  message,  assuming  you've  made  a logical 
error.  By  intentionally  leaving  the  argument  name  out,  you 
suppress  this  warni  ng. 

M ore  i mportant,  if  you  start  out  using  a function  argument  and 
later  decidethat  you  don't  need  it,  you  can  effectively  remove  it 
without  generating  warnings,  and  yet  not  disturb  any  client  code 
that  was  cal  I i ng  the  previous  version  of  the  function. 


Choosing  overloading  vs.  default 
arguments 

Both  function  overloading  and  default  arguments  provide  a 
convenience  for  cal  ling  function  names.  However,  it  can  seem 
confusing  at  times  to  know  which  technique  to  use.  For  example. 
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consider  the  foil  owing  tool  that  is  designed  to  automatically 
manage  blocks  of  memory  for  you: 

// : CO 7 :Mem. h 
#ifndef  MEM_H 
#define  MEM_H 

typedef  unsigned  char  byte; 

class  Mem  { 
byte*  mem; 
int  size; 

void  ensureMinSize ( int  minSize); 
public : 

Mem ( ) ; 

Mem (int  sz)  ; 

-Mem ( ) ; 

int  msize  ( ) ; 

byte*  pointer  0; 

byte*  pointer (int  minSize); 

}; 

#endif  //  MEM_H  ///:- 

A M em  object  holds  a block  of  bytes  and  makes  sure  that  you  have 
enough  storage.  The  default  constructor  doesn't  allocate  any 
storage,  and  the  second  constructor  ensures  that  there  is  sz  storage 
in  the  M em  object.  The  destructor  releases  the  storage,  msize(  )tel  Is 
you  how  many  bytes  there  are  currently  i n the  M em  object,  and 
pointer!  )produces  a pointer  to  the  starting  address  of  the  storage 
(Mem  is  a fairly  low-level  tool).  There's  an  overloaded  version  of 
pointer!  )in  which  client  programmers  can  say  that  they  want  a 
pointer  to  a block  of  bytes  that  is  at  least  minSizelarge,  and  the 
member  function  ensures  this. 

Both  the  constructor  and  the  pointer!  )member  function  use  the 
privateensureM  inSize!  )member  function  to  increase  the  size  of 
the  memory  block  (notice that  it's  not  safeto  hold  the  result  of 
pointer!  )if  the  memory  is  resized). 

Here's  the  implementation  of  the  cl  ass: 

//:  C07:Mem.cpp  {0} 
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#include  "Mem.h" 

#include  <cstring> 
using  namespace  std; 

Mem: :Mem()  { mem  =0;  size=0;  } 

Mem::Mem(int  sz)  { 
mem  = 0 ; 
size  = 0; 

ensureMinSize  (sz) ; 

} 

Mem::~Mem()  { delete  []mem;  } 

int  Mem::msize()  { return  size;  } 

void  Mem :: ensureMinSize ( int  minSize)  { 
if (size  < minSize)  { 

byte*  newmem  = new  byte [minSize ] ; 

memset (newmem  + size,  0,  minSize  - size); 

memcpy (newmem,  mem,  size); 

delete  []mem; 

mem  = newmem; 

size  = minSize; 


} 

byte*  Mem :: pointer ( ) { return  mem;  } 

byte*  Mem :: pointer ( int  minSize)  { 
ensureMinSize (minSize)  ; 
return  mem; 

} ///:- 

You  can  seethatensureM  inSize(  )stheonly  function  responsible 
for  allocating  mennory,  and  that  it  is  used  from  the  second 
constructor  and  the  second  overloaded  form  of  pointer( ) Inside 
ensureM  inSize(  ,)nothi  ng  needs  to  be  done  if  the  size  is  large 
enough.  If  new  storage  must  deallocated  in  order  to  make  the 
block  bigger  (which  is  also  the  case  when  the  block  is  of  size  zero 
after  default  construction),  the  new  "extra"  portion  is  set  to  zero 
using  the  Standard  C library  function  memset( ) which  was 
introduced  in  Chapter  5.  The  subsequent  function  call  istothe 
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standard  C library  function  memcpy( ) which  in  this  case  copies 
the  existing  bytes  from  mem  to  newmem  (typically  in  an  efficient 
fashion).  Finally,  theold  memory  isdeleted  and  the  new  memory 
and  sizes  are  assigned  to  the  appropriate  members. 

The  Mem  class  is  designed  to  be  used  as  a tool  within  other  classes 
to  simplify  their  memory  management  (it  could  also  be  used  to 
hidea  more  sophisticated  memory-management  system  provided, 
for  example,  by  the  operating  system).  Appropriately,  it  istested 
here  by  creating  a simple  "string"  class: 

//:  C07 :MemTest . cpp 
//  Testing  the  Mem  class 
//{L}  Mem 
#include  "Mem.h" 

#include  <cstring> 

#include  <iostream> 
using  namespace  std; 

class  MyString  { 

Mem*  buf; 
public : 

MyString ( ) ; 

MyString (char*  str) ; 

-MyString  ( ) ; 

void  concat (char*  str) ; 

void  print (ostream&  os); 

}; 


MyString :: MyString ( ) { buf  = 0;  } 

MyString: :MyString (char*  str)  { 
buf  = new  Mem (strlen (str)  + 1); 
strcpy ( (char* )buf->pointer ()  , str)  ; 

} 

void  MyString :: concat (char*  str)  { 
if(!buf)  buf  = new  Mem; 
strcat ( (char* ) buf ->po inter ( 

buf->msize()  + strlen (str)  + 1),  str); 

} 
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void  MyString :: print (ostream&  os)  { 
if(!buf)  return; 
os  <<  buf->pointer ( ) <<  endl; 

} 

MyString :: -MyString ( ) { delete  buf;  } 


int  main  ( ) { 

MyString  s("My  test  string"); 

s . print (cout ) ; 

s.concatC  some  additional  stuff"); 

s . print (cout ) ; 

MyString  s2; 

s2 . concat ( "Using  default  constructor"); 

s2 . print (cout ) ; 

} ///:- 

All  you  can  do  with  thisclass  isto  create  a MyString  concatenate 
text,  and  print  to  an  ostream  The  class  only  contains  a pointer  to  a 
M em,  but  note  the  distinction  between  the  default  constructor, 
which  sets  the  pointer  to  zero,  and  the  second  constructor,  which 
creates  a M em  and  copies  data  i nto  it.  The  advantage  of  the  default 
constructor  isthat  you  can  create,  for  example,  a large  array  of 
empty  MyStringobjects  very  cheaply,  sincethe  size  of  each  object 
is  only  one  poi  nter  and  the  only  overhead  of  the  default  constructor 
is  that  of  assigning  to  zero.  The  cost  of  a M yStringonly  begins  to 
accrue  when  you  concatenate  data;  at  that  poi  nt  the  M em  object  is 
created  if  it  hasn't  been  already.  However,  if  you  use  the  default 
constructor  and  never  concatenate  any  data,  the  destructor  call  is 
still  safe  because  cal  ling  deletefor  zero  is  defined  such  that  it  does 
not  try  to  release  storage  or  otherwise  cause  problems. 

I f you  I ook  at  these  two  constructors  it  mi  ght  at  f i rst  seem  I i ke  thi  s 
is  a prime  candidate  for  default  arguments.  However,  if  you  drop 
the  default  constructor  and  writethe  remaining  constructor  with  a 
default  argument: 

MyString (char*  str  = ""); 
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everything  will  work  correctly,  but  you'll  lose  the  previous 
efficiency  benefit  si  nee  a Mem  object  will  always  becreated.Toget 
the  efficiency  back,  you  must  modify  the  constructor: 

MyString: :MyString (char*  str)  { 

if(!*str)  { //  Pointing  at  an  empty  string 
buf  = 0; 
return ; 


buf  = new  Mem (strlen (str)  + 1); 
strepy ( (char* )buf->pointer ()  , str)  ; 

} 

This  means,  in  effect,  that  the  default  value  becomes  a flag  that 
causes  a separate  piece  of  code  to  be  executed  than  if  a non-default 
value  is  used.  Although  it  seems  innocent  enough  with  a small 
constructor  I ike  this  one,  in  general  this  practice  can  cause 
problems.  If  you  have  to  /ookfor  the  default  rather  than  treating  it 
as  an  ordinary  value,  that  should  bea  clue  that  you  will  end  up 
with  effectively  two  different  functions  inside  a single  function 
body:  one  version  for  the  normal  case  and  one  for  the  default.  You 
might  as  well  split  it  up  into  two  distinct  function  bodies  and  let  the 
compiler  do  the  selection.  This  results  in  a slight  (but  usually 
invisible)  increase  in  efficiency,  because  the  extra  argument  isn't 
passed  and  the  extra  codefor  the  conditional  isn't  executed.  More 
importantly,  you  are  keeping  the  codefor  two  separate  functions  in 
two  separate  functions  rather  than  combining  them  into  one  using 
default  arguments,  which  will  result  in  easier  maintainability, 
especially  if  the  functions  are  large. 

On  the  other  hand,  consider  the  Mem  class.  If  you  look  at  the 
definitions  of  the  two  constructors  and  thetwo  pointer(  Kunctions, 
you  can  see  that  using  default  arguments  in  both  cases  will  not 
cause  the  member  fu  ncti  on  defi  niti  ons  to  change  at  al  I . Thus,  the 
class  could  easily  be: 

// : CO 7 :Mem2 . h 
#ifndef  MEM2_H 
#define  MEM2_H 
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typedef  unsigned  char  byte; 


class  Mem  { 
byte*  mem; 
int  size; 

void  ensureMinSize ( int  minSize); 
public : 

Mem (int  sz  = 0) ; 

-Mem ( ) ; 
int  msize  ( ) ; 

byte*  pointer (int  minSize  = 0); 

}; 

#endif  //  MEM2_H  ///:- 

Noticethatacall  toensureMinSize(0)A/ill  always  be  quite 
efficient. 

Although  in  both  of  these  cases  I based  someof  thedecision- 
maki  ng  process  on  the  issue  of  efficiency,  you  must  be  careful  not 
to  fal  I i nto  the  trap  of  thi  nki  ng  onl  y about  effi  ci  ency  (fasci  nati  ng  as 
it  is).  The  most  important  issue  in  class  design  is  the  interface  of  the 
class  (its  public  members,  which  are  avail  able  to  the  client 
programmer).  If  these  produce  a class  that  is  easy  to  use  and  reuse, 
then  you  havea  success;  you  can  always tunefor  efficiency  if 
necessary  but  the  effect  of  a cl  ass  that  is  designed  badly  because  the 
programmer  is  over-focused  on  efficiency  issues  can  be  dire.  Your 
primary  concern  should  be  that  the  interface  makes  sense  to  those 
who  use  it  and  who  read  the  resulting  code.  Notice  that  in 
M emT estcppthe  usage  of  M yStringdoes  not  change  regardless  of 
whether  a default  constructor  is  used  or  whether  the  efficiency  is 
high  or  low. 


Summary 

Asa  guideline,  you  shouldn't  use  a default  argument  as  a flag  upon 
which  to  conditionally  execute  code.  You  should  instead  break  the 
function  into  two  or  more  overloaded  functions  if  you  can.  A 
default  argument  should  be  a value  you  would  ordinarily  put  in 
that  position.  It's  a value  that  is  more  likely  to  occur  than  all  the 
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rest,  so  client  programmers  can  generally  ignore  it  or  use  it  only  if 
they  want  to  change  it  from  the  default  value. 

Thedefault  argument  is  included  to  make  function  calls  easier, 
especially  when  those  functions  have  many  arguments  with  typical 
values.  Not  only  isitmuch  easier  to  write  the  calls,  it'seasierto 
read  them,  especially  if  the  cl  ass  creator  can  order  the  arguments  so 
the  least-modified  defaults  appear  latest  in  the  list. 

An  especially  important  use  of  default  arguments  is  when  you  start 
out  with  a function  with  a set  of  arguments,  and  after  it's  been  used 
forawhileyou  discover  you  need  to  add  arguments.  By  defaulting 
all  the  new  arguments,  you  ensure  that  all  client  code  using  the 
previous  interface  is  not  disturbed. 


Exercises 

Solutions  to  selected  exercises  can  be  found  in  the  electronic  document  TheThinking  in  C++ Annotated 
Solution  Guide,  aval  I able  for  a small  feefromwww.BruceEckel.com. 

1.  CreateaTextclassthatcontainsastringobjectto  hold 
thetextof  afile.  Give  it  two  constructors:  a default 
constructor  and  a constructor  that  takes  a string 
argument  that  is  the  name  of  the  file  to  open.  When  the 
second  constructor  is  used,  open  thefileand  read  the 
contents  into  the  string  member  object.  Add  a member 
function  contents(  )to  return  the  string  so  (for  example) 
it  can  be  printed.  In  main( ) open  afileusingTextand 
pri  nt  the  contents. 

2.  Create  a Messaged  ass  with  a constructor  that  takes  a 
singlestringwith  a default  value.  Createa  private 
member  string  and  in  the  constructor  simply  assign  the 
argument  stringto  your  internal  string  Create  two 
overloaded  member  functions  cal  led  print( ) one  that 
takes  no  arguments  and  simply  pri  nts  the  message  stored 
in  the  object,  and  onethat  takes  a string  argument,  which 
it  prints  in  addition  to  the  internal  message.  Does  it  make 
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sense  to  use  this  approach  instead  of  the  one  used  for  the 
constructor? 

3.  Determi  ne  how  to  generate  assembiy  output  with  your 
compiier,  and  run  experi  ments  to  deduce  the  name- 
decoration  scheme. 

4.  Create  a ci  ass  that  contains  four  member  functions,  with 
0, 1,  2,  and  Bint  arguments,  respectiveiy.  Create  a main( ) 
that  makes  an  object  of  your  dass  and  caiis  each  of  the 
member  functions.  Now  modify  the  dass  so  it  has 
instead  a si  ngie  member  function  with  aii  the  arguments 
defauited.  Does thischange your  main( )? 

5.  Createa  function  with  two  arguments  and  caii  itfrom 
main( ) Now  make  one  of  the  arguments  a "piacehoider" 
(no  identifier)  and  seeif  your  caii  in  main(  )changes. 

6.  M odify  Stash 3.h and  Stash B.cppto  usedefauit 
arguments  in  the  constructor.  Test  the  constructor  by 
maki  ng  two  d ifferent  versi  ons  of  a Stash  object. 

7 . C reate  a new  versi  on  of  the  Stack  ci  ass  (from  C hapter  6) 
that  contains  the  defauit  constructor  as  before,  and  a 
second  constructor  that  takes  as  its  arguments  an  array  of 
pointers  to  objects  and  the  size  of  that  array.  This 
constructor  shouid  move  through  the  array  and  push 
each  pointer  onto  the  Stack  Test  your  dass  with  an  array 
of  string 

8.  Modify  SuperVarsothatthereare#ifdefearound  aii  the 
vartypecode  as  described  in  the  section  on  enum.  Make 
vartypea  reguiar  and  pubiicenumeration  (with  no 
instance)  and  modify  print(  )sothat  it  requiresa  vartype 
argument  to  teii  it  what  to  do. 

9.  impiement  Mem2.hand  make  surethat  the  modified 
dassstiii  works  with  MemTestxpp 

10.  Useciass  Memto  impiement  Stash.  Notethat  because 
theimpiementation  isprivateand  thus  hidden  from  the 
ci  ient  programmer,  the  test  code  does  not  need  to  be 
modified. 
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11.  In  class  Mem  add  a bool  moved(  )mennber  function  that 
takesthe  result  of  a call  topolnter(  )and  tellsyou 
whether  the  pointer  has  moved  (dueto  reallocation). 
Writea  main(  )that  tests  your  moved(  )member 
function.  Does  it  make  more  sense  to  use  something  like 
moved(  )or  to  simply  call  polnter(  )every  ti  me  you  need 
to  access  the  memory  in  M em? 
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8:  Constants 

The  concept  of  constant  (expressed  by  the  const 
keyword)  was  created  to  allow  the  programmer  to 
draw  a line  between  what  changes  and  what  doesn't. 
This  provides  safety  and  control  in  a C++ 
programming  project. 
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Since  its  origin,  consthas  taken  on  a number  of  different  purposes. 
In  the  meantime  it  trickled  back  into  theC  language  where  its 
meaning  was  changed.  All  this  can  seem  a bit  confusing  at  first,  and 
in  this  chapter  you'll  learn  when,  why,  and  how  to  use  the  const 
keyword.  At  the  end  there's  a discussion  of  volatile  which  is  a near 
cousin  to  const(becausethey  both  concern  change)  and  has 
identical  syntax. 

The  fi  rst  moti  vati  on  for  constseems  to  have  been  to  el  i mi  nate  the 
use  of  preprocessor  #def  I nes  for  valuesubstitution.  It  has  si  nee 
been  put  to  use  for  pointers,  function  arguments,  return  types,  class 
objects  and  member  functions.  All  of  these  have  slightly  different 
but  conceptually  compatible  meanings  and  will  be  looked  at  in 
separate  secti  ons  i n thi  s chapter. 


Value  substitution 

When  programming  in  C,  the  preprocessor  is  liberally  used  to 
create  macros  and  to  substitute  values.  Because  the  preprocessor 
si  mply  does  text  replacement  and  has  no  concept  nor  fad  I ity  for 
type  check!  ng,  preprocessor  valuesubstitution  introduces  subtle 
problems  that  can  be  avoided  in  C++ by  using  constvalues. 

The  typical  use  of  the  preprocessor  to  substitute  values  for  names 
in  C looks  I ike  this: 

I #define  BUFSIZE  100 

BUFSIZEisa  namethatonly  exists  during  preprocessing,  therefore 
it  doesn't  occupy  storage  and  can  be  placed  in  a header  fileto 
provide  a single  value  for  all  translation  units  that  use  it.  It'svery 
important  for  code  maintenance  to  use  value  substitution  instead  of 
so-called  "magic  numbers."  If  you  use  magic  numbers  in  your 
code,  not  only  does  the  reader  have  no  idea  where  the  numbers 
come  from  or  what  they  represent,  but  if  you  decide  to  change  a 
value,  you  must  perform  hand  editing,  and  you  have  no  trail  to 
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follow  to  ensure  you  don't  miss  one  of  your  values  (or  accidentally 
change  one  you  shouldn't). 

M ost  of  the  ti  me,  BUFSIZEwill  behave  likean  ordinary  variable, 
but  not  all  the  time.  In  addition,  there's  no  type  information.  This 
can  hi  debugs  that  are  very  difficult  to  find.  C++ uses  con  stto 
el  i mi  nate  these  probi  ems  by  bri  ngi  ng  val  ue  su bstituti  on  i nto  the 
domain  of  the  compiler.  Now  you  can  say 

I const  int  bufsize  = 100; 

You  can  use  bufsizeanyplace  where  the  compiler  must  know  the 
val  ue  at  compi  I e ti  me.  The  compi  I er  can  use  buf  sizeto  perform 
constant  fo/cf/ng,  which  means  the  compiler  will  reducea 
complicated  constant  expression  to  a simple  one  by  performing  the 
necessary  cal  cu  I ati  ons  at  compi  I e ti  me.  Thi  s i s especi  al  I y i mportant 
in  array  definitions: 

I char  buf [buf size] ; 

You  can  useconstfor  all  the  built-in  types  (char,  int  float  and 
double^  and  their  variants  (as  well  as  class  objects,  as  you'll  see 
later  in  thischapter).  Because  of  subtle  bugs  that  the  preprocessor 
might  introduce,  you  should  always  use constinstead  of  #define 
value  substitution. 

const  in  header  files 

To  use  constinstead  of#definayou  must  be  able  to  place  const 
definitions  inside  header  files  as  you  can  with  #define  Thi  sway, 
you  can  placethedefinition  for  aconstin  a single  place  and 
d i stri  bute  it  to  transi  ati  on  u nits  by  i ncl  ud  i ng  the  header  f i I e.  A 
constin  C-h- defaults  to  internal  linkage, that  is,  it  is  visibleonly 
within  thefile  where  it  is  defined  and  cannot  be  seen  at  link  time  by 
other  translation  units.  You  must  always  assign  a value  to  a const 
when  you  define  it,  e>(cept  when  you  make  an  explicit  declaration 
using  extern: 
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I extern  const  int  bufsize; 

Normally,  the  C++ compiler  avoids  creating  storage  for  a const  but 
instead  holds  the  definition  in  its  symbol  table.  When  you  use 
extern  with  const  however,  you  force  storage  to  be  allocated  (this 
is  also  true  for  certain  other  cases,  such  as  taking  the  address  of  a 
const-  Storage  must  be  al  located  because  extern  says  "use  external 
linkage,"  which  means  that  several  translation  units  must  beableto 
refer  to  the  item,  which  requires  it  to  have  storage. 

In  the  ordinary  case,  when  extern  is  not  part  of  the  definition,  no 
storage  is  allocated.  When  the constis  used,  it  is  simply  folded  in  at 
compile  time. 

The  goal  of  never  al  I ocati  ng  storage  for  a constal  so  fai  I s w ith 
complicated  structures.  Whenever  the  compiler  must  allocate 
storage,  constant  folding  is  prevented  (si  nee  there's  no  way  for  the 
compi  I er  to  know  for  su  re  w hat  the  val  ue  of  that  storage  i s - i f i t 
could  know  that,  it  wouldn't  need  to  allocate  the  storage). 

Because  the  compi  I er  cannot  always  avoid  al  I ocati  ng  storage  for  a 
const  constdefi  nitions  must  default  to  i nternal  I i nkage,  that  is, 
linkage  only  within  that  particular  translation  unit.  Otherwise, 
linker  errors  would  occur  with  complicated  const  because  they 
cause  storage  to  be  allocated  in  multiplecppfiles.  The  linker  would 
then  see  the  same  definition  in  multipleobject  files,  and  complain. 
Because  a constdefaults  to  internal  linkage,  the  linker  doesn't  try  to 
I ink  those  definitions  across  translation  units,  and  there  are  no 
collisions.  With  built-in  types,  which  areused  in  the  majority  of 
cases  involving  constant  expressions,  the  compiler  can  always 
perform  constant  folding. 

Safety  consts 

The  use  of  constis  not  limited  to  replacing  #defines  in  constant 
expressions.  If  you  initializea  variablewith  a valuethatis 
produced  at  runtime  and  you  know  it  will  not  change  for  the 
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lifetimeof  that  variable,  it  isgood  programming  practice  to  make  it 
a constso  the  compiler  will  give  you  an  error  message  if  you 
accidentally  try  to  change  it.  Here's  an  example: 

//:  COS : Safecons . cpp 
//  Using  const  for  safety 
#include  <iostream> 
using  namespace  std; 

const  int  i = 100;  //  Typical  constant 
const  int  j = i + 10;  //  Value  from  const  expr 
long  address  = (long)&j;  //  Forces  storage 
char  buf[j  + 10];  //  Still  a const  expression 

int  main  ( ) { 

cout  <<  "type  a character  & CR:"; 
const  char  c = cin.getO;  //  Can't  change 
const  char  c2  = c + 'a'; 
cout  <<  c2; 

//  . . . 

} ///:- 

You  can  see  that  i is  a compi  I e-time  const  but  j iscalculated  from  i. 
However,  because!  is  a const  the  calculated  value  for  j still  comes 
from  a constant  expression  and  is  itself  a compile-time  constant. 
The  very  next  I i ne  requires  the  ad  dress  of  j and  therefore  forces  the 
compiler  to  allocatestoragefor  j.  Yetthisdoesn't  prevent  the  use  of 
j in  the  determination  of  the  size  of  buf  because  the  compiler 
knowsj  isconstand  that  the  value  is  valid  even  ifstoragewas 
allocated  to  hold  that  value  at  some  point  in  the  program. 

In  main(  )you  seea  different  kind  of  constin  the  identifier  c 
because  the  val  ue  cannot  be  known  at  compi  le  ti  me.  Thi  s means 
storage  is  required,  and  the  compiler  doesn't  attempt  to  keep 
anything  in  its  symbol  table  (the  same  behavior  as  in  C).The 
initialization  must  still  happen  at  the  point  of  definition,  and  once 
the  initialization  occurs,  the  valuecannot  be  changed.  You  can  see 
that  c2  is  calculated  from  c and  also  that  scoping  works  for  consfe 
as  it  does  for  any  other  type  - yet  another  i mprovement  over  the 
useof  #define 


8:  Constants 


357 


Asa  matter  of  practice,  if  you  think  a value  should  n't  change,  you 
should  make  it  a const  This  not  only  provides  insurance  against 
i nad vertent  changes,  it  al  so  al  I ows  the  compi  I er  to  generate  more 
efficient  code  by  eliminating  storage  and  memory  reads. 

Aggregates 

It's  possible  to  use  constfor  aggregates,  but  you're  virtually 
assured  that  the  compiler  will  not  be  sophisticated  enough  to  keep 
an  aggregatein  its  symbol  table,  so  storagewill  be  allocated.  In 
these  situations,  constmeans  "a  piece  of  storage  that  cannot  be 
changed."  However,  the  value  cannot  be  used  at  compile  time 
because  the  compi  I er  i s not  requ  i red  to  know  the  contents  of  the 
storage  at  compile  time.  In  the  following  code,  you  can  seethe 
statements  that  are  i 1 1 egal : 

//:  COS : Constag . cpp 
//  Constants  and  aggregates 
const  int  i[]  = { 1,  2,  3,  4 }; 

//!  float  f[i[3]];  //  Illegal 

struct  S { int  1,  j;  }; 

const  S s[]  = { { 1,  2 } , { 3,  4 } } ; 

//!  double  d[s[l].j];  //  Illegal 
int  main ( ) { } ///  : ~ 

In  an  array  definition,  the  compiler  must  beableto  generate  code 
that  moves  the  stack  pointer  to  accommodate  the  array.  In  both  of 
theillegal  definitions  above,  the  compiler  complains  becauseit 
cannot  find  a constant  expression  in  the  array  definition. 

Differences  with  C 

Constants  were  introduced  in  early  versions  of  C++ whilethe 
Standard  C specification  was  still  being  finished.  Although  the C 
committee  then  decided  to  includeconstin  C,  somehow  it  came  to 
mean  for  them  "an  ordinary  variable  that  cannot  be  changed."  In  C, 
a constalways  occupies  storage  and  its  name  is  global.  The  C 
compiler  cannot  treat  a constas  a compi  I e-time  constant.  InC,  if 
you  say 
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const  int  bufsize  = 100; 
char  buf [bufsize] ; 

you  will  get  an  error,  even  though  itseennslikea  rational  thing  to 
do.  Because  bufsizeoccupies  storage  somewhere,  the  C compiler 
cannot  know  the  value  at  compile  time.  You  can  optionally  say 

const  int  bufsize; 

in  C,  but  not  in  C++,  and  theC  compiler  accepts  it  as  a declaration 
indicating  there  is  storage  allocated  elsewhere.  BecauseC  defaults 
to  external  linkagefor  const,  this  makes  sense.  C++defaultsto 
internal  linkage  for  const  so  if  you  want  to  accomplish  the  same 
thing  in  C++,  you  must  explicitly  change  the  linkage  to  external 
using  extern: 

extern  const  int  bufsize;  //  Declaration  only 

This  linealso  works  in  C. 

I n C ++,  a constdoesn't  necessari  ly  create  storage.  I n C a const 
always  creates  storage.  Whether  or  not  storage  is  reserved  for  a 
constin  C++dependson  how  it  isused.  In  general,  if  aconstis 
used  simply  to  replacea  name  with  a value  (just  as  you  would  use 
a #defin^,  then  storage  doesn't  have  to  be  created  for  the  const  If 
no  storage  is  created  (this  depends  on  the  complexity  of  the  data 
type  and  the  sophistication  of  the  compiler),  the  values  may  be 
folded  into  the  codefor  greater  efficiency  after  type  checking,  not 
before,  as  with  #define  If,  however,  you  take  an  address  of  a const 
(even  unknowingly,  by  passing  it  to  a function  that  takes  a 
reference  argument)  or  you  defi  ne  it  as  extent  then  storage  is 
created  for  the  const 

In  C++,  aconstthat  isoutsideall  functions  has  filescope(i.e.,  it  is 
invisibleoutsidethefile).That  is,  it  defaults  to  internal  linkage. 

This  is  very  different  from  all  other  identifiers  in  C++(and  from 
constin  C!)  that  default  to  external  linkage.  Thus,  if  you  declare  a 
constofthesamename  in  two  different  files  and  you  don't  takethe 
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add  ress  or  def i ne  that  name  as  extern  the  i deal  C ++  compi  I er 
won't  allocate  storage  for  the  const  but  simply  fold  It  Into  the  code. 
Because consthas  Implied  fllescope,  you  can  put  It  In  C++ header 
files  with  no  conflicts  at  link  time. 

SInceaconstIn  C++defaults  to  Internal  linkage,  you  can't  just 
define  a constin  onefileand  reference  It  as  an  externin  another 
file.  Togiveaconstexternal  linkage  so  It  can  be  referenced  from 
another  file,  you  must  explicitly  define  It  as  extent  llkethls: 

extern  const  int  x = 1; 

Notice  that  by  giving  It  an  Initializer  and  saying  ltlsexteri\  you 
force  storage  to  be  created  for  theconst(although  the  compiler  still 
has  the  option  of  doing  constant  folding  here).  The  Initialization 
establishes  this  as  a definition,  not  a declaration.  The  declaration: 

extern  const  int  x; 

In  C++ means  that  the  definition  exists  elsewhere  (again,  this  Is  not 
necessarily  true  In  C).  You  can  now  see  why  C++ requires  a const 
defi  nl tl  on  to  have  an  I nitl al  Izer:  the  I nitl  al  Izer  d I sti  ngu  I shes  a 
declaration  from  a definition  (In  C It's  always  a definition,  so  no 
Initializer  Is  necessary).  With  an  extern constd eel aratl on,  the 
compiler  cannot  do  constant  folding  because  It  doesn't  know  the 
value. 

TheC  approach  to  consti  snot  very  useful,  and  If  you  want  to  use  a 
named  value  Inside  a constant  expression  (one that  must  be 
evaluated  atcomplletime),  C al  most  forces  you  to  use  #defineln 
the  preprocessor. 


Pointers 

Pointers  can  be  madeconst  The  compiler  will  still  endeavor  to 
prevent  storage  allocation  and  do  constant  folding  when  dealing 
with  const  pointers,  but  these  features  seem  less  useful  In  this  case. 
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More  importantly,  the  compiler  will  tell  you  if  you  attempt  to 
change  a const  pointer,  which  adds  a great  deal  of  safety. 

When  using  constwith  pointers,  you  have  two  options:  constcan 
be  applied  to  what  the  pointer  is  pointing  to,  or  the  constcan  be 
applied  to  the  address  stored  in  the  pointer  itself.  The  syntax  for 
these  is  a little  confusing  at  first  but  becomes  comfortable  with 
practice. 

Pointer  to  const 

The  trick  with  a pointer  definition,  as  with  any  complicated 
definition,  is  to  read  it  starting  at  the  identifier  and  work  your  way 
out.  Theconstspecifier  binds  to  the  thing  it  is  "closest  to."  So  if  you 
want  to  prevent  any  changes  to  the  element  you  are  poi  nti  ng  to, 
you  write  a definition  I ike  this: 

I const  int*  u; 

Starting  from  the  identifier,  we  read  "u  is  a pointer,  which  points  to 
aconstint"  Here,  no  initialization  is  required  because  you're 
saying  thatu  can  point  to  anything  (that  is,  it  isnotcons^,  but  the 
thing  it  points  to  cannot  be  changed. 

Here's  the  mi  Idly  confusing  part.  You  might  think  that  to  make  the 
pointer  itself  unchangeable,  that  is,  to  prevent  any  change  to  the 
address  contained  inside  u,  you  would  simply  move  the  constto 
the  other  si  d e of  the  i nt  I i ke  thi  s: 

I int  const*  v; 

It's  not  all  that  crazy  to  think  that  this  should  read  "vis  a const 
pointer  to  an  int"  However,  theway  \tactually  readsis"v  isan 
ordinary  pointer  to  an  intthat  happens  to  be  const"  That  is,  the 
consthas  bound  itself  to  the  int  again,  and  the  effect  isthesameas 
the  previous  definition.  The  fact  that  thesetwo  definitions  are  the 
same  is  the  confusing  point;  to  prevent  this  confusion  on  the  part  of 
your  reader,  you  should  probably  stick  to  the  first  form. 
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const  pointer 

To  make  the  pointer  itself  a const  you  must  place  the  const 
specif i er  to  the  ri ght  of  the *,  I i ke  this: 

int  d = 1; 

int*  const  w = &d; 

Now  it  reads:  "w  is  a pointer,  which  is  const  that  points  to  an  int" 
Because  the  pointer  itself  is  now  the  const  the  compiler  requires 
that  it  begiven  an  initial  valuethat  will  be  unchanged  for  thelifeof 
that  pointer.  It'sOK,  however,  to  change  what  that  value  points  to 
by  saying 

I *W  = 2; 

You  can  also  makeaconstpointertoaconstobjectusing  either  of 
two  legal  forms: 

int  d = 1; 

const  int*  const  x = &d;  //  (1) 

int  const*  const  x2  = &d;  //  (2) 

N ow  neither  the  poi  nter  nor  the  object  can  be  changed . 

Some  people  argue  that  the  second  form  is  more  consistent  because 
the constis  always  placed  totheright  of  what  it  modifies.  You'll 
have  to  decide  which  is  clearer  for  your  particular  coding  style. 

H ere  are  the  above  I i nes  i n a compi  I eabi  e f i I e: 

//:  COS : ConstPointers . cpp 

const  int*  u; 

int  const*  v; 

int  d = 1; 

int*  const  w = &d; 

const  int*  const  x = &d;  //  (1) 

int  const*  const  x2  = &d;  //  (2) 

int  main ( ) { } ///  : ~ 
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Formatting 

This  book  makes  a point  of  only  putting  one  pointer  definition  on  a 
I i ne,  and  i niti  al  i zi  ng  each  poi  nter  at  the  poi  nt  of  defi  ni ti  on 
whenever  possible.  Because  of  this,  theformatting  styleof 
"attaching"  the  to  thedata  type  is  possible: 

I int*  u = &i; 

as /finf'were  a discrete  type  unto  itself.  This  makes  the  code  easier 
to  understand,  but  unfortunately  that's  not  actually  the  way  things 
work.  The'*'  in  fact  binds  to  the  identifier,  not  the  type.  It  can  be 
placed  anywhere  between  the  type  name  and  the  identifier.  So  you 
could  do  this: 

I int  *u  = &i,  V = 0; 

which  creates  an  int*  u,  as  before,  and  a non-poi  nter  int  v.  Because 
readers  often  find  this  confusing,  it  is  best  to  follow  theform  shown 
in  this  book. 

Assignment  and  type  checking 

C++isvery  particular  about  type  checking,  and  thisextendsto 
pointer  assignments.  You  can  assign  the  address  of  a non-const 
object  to  a constpoi  nter  because  you're  simply  promising  not  to 
change  something  that  is  OK  to  change.  However,  you  can't  assign 
the  address  of  a constobject  to  a non-constpointer  because  then 
you're  saying  you  might  change  the  object  via  the  poi  nter.  Of 
course,  you  can  always  use  a cast  to  force  such  an  assignment,  but 
this  is  bad  programming  practice  because  you  are  then  breaking  the 
conslness  of  the  object,  along  with  any  safety  promised  by  the 
const  For  example: 

//:  COS : PointerAssignment . cpp 
int  d = 1; 
const  int  e = 2; 

int*  u = &d;  //  OK  — d not  const 

//!  int*  V = &e;  //  Illegal  — e const 

int*  w = (int*)&e;  //  Legal  but  bad  practice 
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int  main  ( ) { } / / / : ~ 


Although  C++ helps  prevent  errors  it  does  not  protect  you  from 
yourself  if  you  want  to  break  the  safety  mechanisms. 

Character  array  literals 

The  pi  ace  w here  strictconstness  I snot  enforced  is  with  character 
array  literals.  You  can  say 

char*  cp  = "howdy"; 

and  the  compiler  will  accept  itwithout  complaint.  This  is 
technically  an  error  because  a character  array  literal  ("howdy"!  n 
this  case)  is  created  by  the  compiler  as  a constant  character  array, 
and  the  result  of  the  quoted  character  array  is  its  starting  address  in 
memory.  Modifying  any  of  the  characters  in  the  array  isa  runtime 
error,  although  not  all  compilers  enforce  this  correctly. 

So  character  array  literals  are  actually  constant  character  arrays.  Of 
course,  the  compiler  lets  you  getaway  with  treating  them  as  non- 
constbecause there's  so  much  existing  C codethat  relies  on  this. 
However,  if  you  try  to  change  the  values  in  a character  array  literal, 
the  behavior  is  undefined,  although  itwill  probably  work  on  many 
machines. 

If  you  want  to  beableto  modify  the  string,  put  it  in  an  array: 

char  cp [ ] = "howdy"; 

Since  compilers  often  don't  enforce  the  difference  you  won't  be 
reminded  to  use  this  latter  form  and  so  the  point  becomes  rather 
subtle. 


Function  arguments 
& return  values 

Theuseof  constto  specify  function  arguments  and  return  values  is 
another  place  where  the  concept  of  constants  can  be  confusing.  If 
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you  are  passing  objects  by  value,  specifying  consthas  no  meaning  to 
the  client  (it  means  that  the  passed  argument  cannot  be  modified 
inside  the  function).  If  you  are  returning  an  objectof  a user-defined 
type  by  value  as  a const  it  means  the  returned  value  cannot  be 
modified.  If  you  are  passing  and  returning  addresses,  constisa 
promise  that  the  destination  of  the  address  will  not  be  changed. 

Passing  by  const  value 

You  can  specify  that  function  arguments  areconstwhen  passing 
them  by  value,  such  as 

void  fl (const  int  i)  { 

i++;  //  Illegal  — comp lie -time  error 

} 

but  what  does  this  mean?  You're  making  a promise  that  the 
original  value  of  the  variable  will  not  be  changed  by  the  function 
fia  H owever,  because  the  argument  is  passed  by  value,  you 
immediately  make  a copy  of  the  original  variable,  so  the  promise  to 
the  cl  lent  is  implicitly  kept. 

Insidethe function,  theconsttakeson  meaning:  the  argument 
cannot  be  changed.  So  it's  real  ly  a tool  for  the  creator  of  the 
function,  and  not  the  caller. 

To  avoid  confusion  to  the  caller,  you  can  make  the  argument  a 
const/ns/dethefunction,  rather  than  in  the  argument  list.  You 
could  do  this  with  a pointer,  but  a nicer  syntax  is  achieved  with  the 
reference,  a subject  that  will  be  fully  developed  in  Chapter  11. 

Bri  efi  y , a reference  i s I i ke  a constant  poi  nter  that  i s automati  cal  I y 
dereferenced,  so  it  has  the  effect  of  being  an  alias  to  an  object.  To 
create  a reference,  you  use  the  & in  the  definition.  So  the  non- 
confusing function  definition  looks  I ike  this: 

void  f2 (Int  Ic)  { 
const  lnt&  1 = Ic; 

1++;  //  Illegal  — complle-tlme  error 

} 
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Again,  you'll  get  an  error  message,  but  this  time  the  constness  of 
the  local  object  is  not  part  of  the  function  signature;  it  only  has 
meaning  to  the  implementation  of  the  function  and  therefore  it's 
hidden  from  the  cl  lent. 


Returning  by  const  value 

A similar  truth  holds  for  the  return  value.  If  you  say  that  a 
function's  return  value  is  const 

I const  int  g ( ) ; 

you  are  promising  that  the  original  variable  (insidethefunction 
frame)  will  not  be  modified.  And  again,  because  you're  returning  it 
by  value,  it'scopied  so  the  original  value  could  never  be  modified 
via  the  return  value. 

Atfirst,  thiscan  make  the  specif!  cation  of  constseem  meaningless. 
You  can  seetheapparentlackof  effect  of  returning  const  by  value 
in  this  example: 

//:  COS : Constval . cpp 

//  Returning  consts  by  value 

//  has  no  meaning  for  built-in  types 

int  f3()  { return  1;  } 

const  int  f4()  { return  1;  } 

int  main  ( ) { 

const  int  j = f3();  //  Works  fine 

int  k = f4();  //  But  this  works  fine  too! 

} ///:- 

For  built-in  types,  it  doesn't  matter  whether  you  return  by  value  as 
a const  so  you  should  avoid  confusing  the  cl  lent  programmer  and 
leave  off  the  constwhen  returning  a bui  It-i  n type  by  value. 

Returning  by  value  as  a constbecomes  important  when  you're 
dealing  with  user-defined  types.  If  afunction  returns  a class  object 
by  val  ue  as  a const  the  return  val  ue  of  that  fu  ncti  on  cannot  be  an 
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lvalue  (that  is,  it  cannot  be  assigned  to  or  otherwise  modified).  For 
example: 

//:  COS : ConstReturnValues . cpp 
//  Constant  return  by  value 
//  Result  cannot  be  used  as  an  lvalue 

class  X { 

Int  1 ; 
public : 

X ( int  11  = 0 ) ; 
void  modify ( ) ; 

}; 

X::X(int  11)  { 1 = 11;  } 

void  X::modify()  { 1++;  } 

X f5()  { 

return  X ( ) ; 

} 

const  X f 6 ( ) { 

return  X ( ) ; 

} 

void  f7 (X&  x)  { //  Pass  by  non-const  reference 
X . modify ( ) ; 

} 

int  main  ( ) { 

f5()  = X(l);  //  OK  — non-const  return  value 
f 5 0 .modify  0 ; //  OK 
//  Causes  compile-time  errors: 

//!  f7(f50); 

//!  f6()  = X(l); 

// ! f 6 ( ) .modify  ( ) ; 

//!  f7(f60); 

} ///:- 

f5( ) returns  a non-constX  object,  while f6( ) returns  a const  X 
object.  Only  the  non-constreturn  valuecan  be  used  as  an  lvalue. 
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Thus,  it's  important  to  use constwhen  returning  an  object  by  value 
if  you  want  to  prevent  its  use  as  an  lvalue. 

The  reason  consthasno  meaning  when  you're  returning  a built-in 
type  by  val ue  is  that  the  compi  ler  al ready  prevents  it  from  bei  ng  an 
lvalue  (because  it's  always  a value,  and  not  a variable).  Only  when 
you're  returning  objects  of  user-defined  types  by  value  does  it 
become  an  issue. 

Thefunction  f7(  )takes  its  argument  as  a non-constreference  (an 
additional  way  of  handling  addresses  in  C-H-and  the  subject  of 
Chapter  11).  This  is  effectively  the  same  as  taking  a non-const 
poi  nter;  it's  just  that  the  syntax  i s d ifferent.  The  reason  this  won't 
compile  in  C-H- is  because  of  the  creation  of  a temporary. 

Temporaries 

Sometimes,  during  the  evaluation  of  an  expression,  the  compi  ler 
must  create  temporary  objects.  These  are  objects  I i ke  any  other:  they 
require  storage  and  they  must  deconstructed  and  destroyed.  The 
d ifference  i s that  you  never  see  them  - the  compi  I er  i s responsi  bl  e 
for  deciding  that  they're  needed  and  thedetailsof  their  existence. 
But  there  i s one  th i ng  about  temporari  es:  they're  automat!  cal  ly 
const  Because  you  usually  won't  be  able  to  get  your  hands  on  a 
temporary  object,  telling  it  to  do  something  that  will  change  that 
temporary  is  almost  certainly  a mistake  because  you  won't  be  able 
to  use  that  information.  By  making  all  temporaries  automatically 
const  the  compi  ler  informs  you  when  you  make  that  mistake. 

In  the  above  example,  f5( ) returns  a non-constX  object.  But  in  the 
expression: 

f7 (f5  0 ) ; 

the  compi  ler  must  manufacture  a temporary  object  to  hold  the 
return  value  of  f5()  so  it  can  be  passed  tof7(  )iThiswould  befineif 
f7(  )took  its  argument  by  value;  then  the  temporary  would  be 
copied  intof7()and  it  wouldn't  matter  what  happened  to  the 


368 


Thinking  in  C-I--I- 


www.BruceEckel.com 


temporary  X.  H owever,  f7(  )takes  its  argument  by  rd^erence,  which 
means  i n thi  s exampi  e takes  the  add ress  of  the  temporary  X.  Si  nee 
f7(  )doesn't  take  its  argument  by  const  reference,  it  has  permission 
to  modify  the  temporary  object.  But  the  compiler  knowsthatthe 
temporary  will  vanish  as  soon  as  the  expression  evaluation  is 
complete,  and  thus  any  modifications  you  make  to  the  temporary  X 
will  be  lost.  By  making  all  temporary  objects  automatically  const 
this  situation  causes  a compile-time  error  so  you  don't  get  caught 
by  what  would  be  a very  difficult  bug  to  find. 

H owever,  noti  ce  the  express!  ons  that  are  I egal : 

f5  0 = X(l)  ; 

f 5 ( ) .modify ( ) ; 

A Ithough  these  pass  muster  for  the  compi  I er,  they  are  actual  ly 
problematic.  f5( ) returns  an  X object,  and  for  the  compiler  to  satisfy 
the  above  expressions  it  must  create  a temporary  to  hold  that 
return  value.  So  in  both  express!  ons  the  temporary  object  is  being 
modified,  and  as  soon  as  the  express! on  is  over  the  temporary  is 
cleaned  up.  As  a result,  the  modifications  are  lost  so  this  code  is 
probably  a bug  - but  the  compiler  doesn't  tel  I you  anything  about 
it.  Expressions  I ike  these  are  simple  enough  for  you  to  detect  the 
problem,  but  when  things  get  more  complex  it's  possible  for  a bug 
to  si  I p through  these  cracks. 

The  way  theconstness  of  class  objects  is  preserved  is  shown  later  in 
the  chapter. 

Passing  and  returning  addresses 

If  you  pass  or  return  an  address  (either  a pointer  or  a reference),  it's 
possi  bl  e for  the  cl  I ent  programmer  to  take  it  and  mod  ify  the 
original  value.  If  you  make  the  pointer  or  reference  a const  you 
prevent  this  from  happening,  which  may  save  you  somegrief.  In 
fact,  whenever  you're  passing  an  address  into  a function,  you 
should  makeitaconstif  atall  possible.  If  you  don't,  you're 
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excluding  the  possibility  of  using  that  function  with  anything  that 

is  a const 

The  choice  of  whether  to  return  a poi  nter  or  reference  to  a const 
depends  on  what  you  want  to  allow  your  client  programmer  to  do 
with  it.  Here's  an  examplethat  demonstrates  the  use  of  const 
pointers  as  function  arguments  and  return  values: 

//:  COS : ConstPointer . cpp 
//  Constant  pointer  arg/return 

void  t (int*)  { } 

void  u (const  int*  cip)  { 

//!  *cip  = 2;  //  Illegal  — modifies  value 
int  i = *cip;  //  OK  — copies  value 
//!  int*  ip2  = cip;  //  Illegal:  non-const 
} 

const  char*  v()  { 

//  Returns  address  of  static  character  array: 
return  "result  of  function  v()"; 

} 

const  int*  const  w()  { 

static  int  i; 
return  &i; 

} 

int  main  ( ) { 

int  X = 0; 
int*  ip  = &x; 
const  int*  cip  = &x; 
t (ip) ; //  OK 

//!  t (cip) ; //  Not  OK 
u (ip) ; //  OK 

u(cip);  //  Also  OK 
//!  char*  cp  = v ( ) ; //  Not  OK 

const  char*  ccp  = v();  //OK 
//!  int*  ip2  = w();  //  Not  OK 

const  int*  const  ccip  = w ( ) ; //  OK 
const  int*  cip2  = w();  //  OK 
//!  *w()  = 1;  //  Not  OK 
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Thefunctiont(  )takes  an  ordinary  non-constpointer  as  an 
argument,  and  u(  )takesaconstpointer.  Insideu(  )you  can  see 
that  attempt!  ng  to  modify  the  destination  of  the  const  pointer  is 
i 1 1 egal , but  you  can  of  cou  rse  copy  the  i nformati  on  out  i nto  a non- 
constvariable.  The  compiler  also  prevents  you  from  creating  a non- 
constpointer  using  the  address  stored  inside  a constpointer. 

Thefunctionsv(  )and  w(  )test  return  value  semantics.  v(  )returns 
a constchar*that  is  created  from  a character  array  I iteral . This 
statement  actual  ly  produces  the  address  of  the  character  array 
I iteral,  after  the  compiler  creates  it  and  stores  it  in  the  static  storage 
area.  As  mentioned  earlier,  this  character  array  is  technically  a 
constant,  which  is  properly  expressed  by  the  return  value  of  v( ). 

The  return  value  of  w( ) requires  that  both  the  pointer  and  what  it 
points  to  must  be  const  As  with  v( ),  the  value  returned  by  w(  )is 
valid  after  the  function  returns  only  because  it  is  static  You  never 
want  to  return  pointers  to  local  stack  variables  because  they  will  be 
invalid  after  the  function  returns  and  the  stack  is  cleaned  up. 

(A  nother  common  pointer  you  might  return  is  the  ad  dress  of 
storage  allocated  on  the  heap,  which  is  still  valid  after  the  function 
returns.) 

In  main( ) the  functions  are  tested  with  various  arguments.  You 
can  see  that  t(  )will  accept  a non-constpointer  argument,  but  if  you 
try  to  passit  a pointer  to  a const  there's  no  promise  that  t(  )will 
leavethe  pointer's  destination  alone,  so  the  compiler  gives  you  an 
error  message.  u( ) takes  a const poi  nter,  so  it  wi  1 1 accept  both  types 
of  arguments.  Thus,  a function  that  takes  a constpointer  is  more 
general  than  one  that  does  not. 

Asexpected,  the  return  valueof  v(  )can  be  assigned  only  to  a 
poi  nter  to  a const  You  would  also  expect  that  the  compiler  refuses 
to  assign  the  return  valueof  w(  )to  a non-constpointer,  and 
accepts  a const  int*  consitbut  it  might  bea  bit  surprising  to  see  that 
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it  also  accepts  a const  int*  which  is  not  an  exact  match  to  the  return 
type.  Once  again,  because  the  value  (which  is  the  address  contained 
i n the  poi  nter)  i s bei  ng  copi  ed,  the  promi se  that  the  ori  gi  nal 
variable  is  untouched  is  automatically  kept.  Thus,  the  second  const 
in  constint*  const s only  meaningful  when  you  try  to  use  it  as  an 
lvalue,  in  which  case  the  compiler  prevents  you. 

Standard  argument  passing 

I n C it's  very  common  to  pass  by  value,  and  when  you  want  to  pass 
an  address  your  only  choice  is  to  usea  pointer^.  However,  neither 
oftheseapproaches  is  preferred  in  C++.  Instead,  your  first  choice 
when  passing  an  argument  isto  pass  by  reference,  and  by  const 
reference  at  that.  To  the  client  programmer,  the  syntax  is  identical 
to  that  of  passing  by  value,  so  there's  no  confusion  about  pointers- 
they  don't  even  haveto  think  about  pointers.  Forthecreator  of  the 
fu ncti on,  pass!  ng  an  add ress  i s vi rtual  ly  always  more  effi ci ent  than 
pass!  ng  an  enti  re  cl  ass  object,  and  if  you  pass  by  const  reference  it 
means  your  function  will  not  change  the  destination  of  that 
address,  so  the  effect  from  the  cl  lent  programmer's  point  of  view  is 
exactly  the  same  as  pass- by- value  (only  more  efficient). 

Because  of  the  syntax  of  references  (it  looks  I i ke  pass-by-val  ue  to 
the  caller)  it's  possible  to  pass  a temporary  object  to  a function  that 
takes  a constreference,  whereas  you  can  never  pass  a temporary 
object  to  a function  that  takes  a pointer  - with  a pointer,  the  address 
must  be  explicitly  taken.  So  passing  by  reference  produces  a new 
situation  that  never  occurs  in  C:  a temporary,  which  is  always 
const  can  have  its  address  passed  to  a function.  This  is  why,  to 
allow  temporaries  to  be  passed  to  functions  by  reference,  the 
argument  must  be  a const  reference.  The  foil  owing  example 
demonstrates  this: 


^ Some  folks  go  as  far  assaying  that  everything  in  C is  pass  by  value,  since  when  you 
pass  a pointer  a copy  is  made  (so  you're  passing  the  pointer  by  value).  However 
precisethis  might  be,  I think  it  actually  confuses  theissue. 
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//:  COS : ConstTemporary . cpp 
//  Temporaries  are  const 

class  X { } ; 

X f()  { return  X();  } //  Return  by  value 

void  gl(X&)  {}  //  Pass  by  non-const  reference 
void  g2 (const  X&)  {}  //  Pass  by  const  reference 

int  main  ( ) { 

//  Error:  const  temporary  created  by  f ()  : 

//!  gl(fO); 

//  OK:  g2  takes  a const  reference: 
g2 (f 0 ) ; 

} ///:- 

f( ) returns  an  object  of  class  Xby  value.  That  means  when  you 
immediately  take  the  return  valueoff(  )and  pass  it  to  another 
function  as  in  the  cal  Is  to  gl(  )and  g2( ),  a temporary  is  created  and 
that  temporary  i s const  Thus,  the  cal  I in  giO  is  an  error  because 
gl(  )doesn'ttakeaconstreference,  but  the  cal  I to  g2()  isOK. 


Classes 

This  section  shows  the  ways  you  can  useconstwith  classes.  You 
may  want  to  create  a local  constin  a class  to  use  inside  constant 
expressions  that  will  be  evaluated  at  compile  time.  However,  the 
meaning  of  con  stis  different  inside  cl  asses,  so  you  must 
understand  the  options  in  order  to  create  constdata  members  of  a 
class. 

You  can  also  make  an  entire  object  const(and  as  you've  just  seen, 
the  compiler  always  makes  temporary  objects  const).  But 
preserving  theconstness  of  an  object  is  more  complex.  The 
compiler  can  ensuretheconslnessof  a built-in  type  but  it  cannot 
monitor  the  i ntri  caci  es  of  a cl  ass.  T o guarantee  the  constness  of  a 
class  object,  the  const  member  function  is  introduced:  only  a const 
member  function  may  be  called  for  a constobject. 
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const  in  classes 

One  of  the  places  you'd  I i ke  to  use  a constfor  constant  expressions 
is  inside  classes.  The  typical  example  is  when  you're  creating  an 
array  inside  a cl  ass  and  you  want  to  useaconstinstead  of  a 
#defineto  establish  the  array  size  and  to  use  in  calculations 
i nvol  vi  ng  the  array.  The  array  si ze  i s someth!  ng  you'd  I i ke  to  keep 
hidden  inside  the  class,  so  if  you  used  a namelikesizei  for 
example,  you  could  use  that  name  in  another  class  without  a clash. 
The  preprocessor  treats  all  #defineB  as  global  from  the  point  they 
are  defined,  sothiswill  not  achieve  the  desired  effect. 

You  might  assumethat  the  logical  choice  isto  place  a constinside 
theclass.  This  doesn't  produce  thedesired  result.  Insideaclass, 
const  parti  ally  reverts  to  its  meaning  in  C.  It  allocates  storage 
within  each  object  and  represents  a value  that  is  initialized  once 
and  then  cannotchange.  The  use  of  constinside  a class  means 
"This  is  constant  for  the  lifetime  of  the  object."  However,  each 
different  object  may  contain  a different  value  for  that  constant. 

Thus,  when  you  create  an  ordinary  (non-stati<)  constinside  a class, 
you  cannot  give  it  an  initial  value.  This  initialization  must  occur  in 
the  constructor,  of  course,  but  in  a special  place  in  the  constructor. 
Because  a constmust  be  initialized  at  the  point  it  is  created,  inside 
the  main  body  of  the  constructor  the  constmust  already  be 
initialized.  Otherwiseyou're  left  with  the  choice  of  waiting  until 
some  point  later  in  the  constructor  body,  which  means  the  const 
would  beun-initialized  for  a while.  Also,  therewould  be  nothing  to 
keep  you  from  changing  the  value  of  the  constat  various  places  in 
the  constructor  body. 

The  constructor  initializer  list 

The  special  initialization  point  iscalled  the  constructor  initializer  list, 
and  it  was  originally  developed  for  use  in  inheritance  (covered  in 
Chapter  14).  The  constructor  initializer  list-  which,  as  the  name 
implies,  occurs  only  in  the  definition  of  the  constructor-  isa  list  of 
"constructor  calls"  that  occur  after  the  function  argument  list  and  a 
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colon,  but  before  the  opening  brace  of  the  constructor  body.  This  is 
to  remind  you  that  the  initialization  in  the  list  occurs  before  any  of 
the  main  constructor  code  is  executed.  This  is  the  pi  ace  to  put  all 
constinitializations.  The  proper  form  for  constinsidea  class  is 
shown  here: 

//:  COS : Constinitialization . cpp 
//  Initializing  const  in  classes 
#include  <iostream> 
using  namespace  std; 

class  Fred  { 

const  int  size; 
public : 

Fred (int  sz)  ; 
void  print  ( ) ; 

}; 


Fred :: Fred ( int  sz)  : size(sz)  {} 

void  Fred :: print ( ) { cout  <<  size  <<  endl;  } 

int  main  ( ) { 

Fred  a(l),  b(2),  c(3); 
a.printO,  b.printO,  c.printO; 

} ///:- 

The  form  of  the  constructor  initializer  list  shown  above  is  confusing 
at  fi  rst  because  you're  not  used  to  seei  ng  a bui  It-i  n type  treated  as  if 
it  has  a constructor. 

"Constructors"  for  built-in  types 

As  the  language  developed  and  more^ort  was  put  into  making 
user-defined  types  look  like  built-in  types,  it  became  apparent  that 
there  were  times  when  it  was  helpful  to  make  built-in  types  look 
I ike  user-defined  types.  In  the  constructor  initializer  list,  you  can 
treata  built-in  typeas  if  it  has  a constructor,  likethis: 

// : COS : BuiltInTypeConstructors . cpp 
#include  <iostream> 
using  namespace  std; 
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class  B { 
int  i ; 
public : 

B ( int  11 ) ; 
void  print  ( ) ; 

}; 


B:  :B (int  ii)  : i (ii)  { } 

void  B::print()  { cout  <<  i <<  endl;  } 

int  main  ( ) { 

B a(l),  b(2); 
float  pi (3.14159) ; 
a.printO;  b.printO; 
cout  <<  pi  <<  endl; 

} ///:- 

This  is  especially  critical  when  initializing  constdata  members 
because  they  must  be  initialized  before  the  function  body  is 
entered. 

It  made  sense  to  extend  this  "constructor"  for  built-in  types  (which 
simply  means  assignment)  to  the  general  case,  which  is  why  the 
float  pi(3.14159)definition  works  in  the  above  code. 

It'soften  useful  to  encapsulatea  built-in  type  insidea  class  to 
guarantee  initialization  with  the  constructor.  For  example,  here'san 

Integerclass: 

//:  COS : EncapsulatingTypes . cpp 
#include  <iostream> 
using  namespace  std; 

class  Integer  { 
int  i ; 
public : 

Integer (int  ii  = 0); 
void  print  ( ) ; 

}; 


Integer :: Integer  ( int  ii)  : i(ii)  {} 

void  Integer :: print  ( ) { cout  <<  i <<  ' } 
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int  main  ( ) { 

Integer  i [ 100 ] ; 
for(int  j = 0;  j < 100;  j++) 

i [ j]  .print  () ; 

} ///:- 

The  array  of  I ntegeis  i n main(  )areall  automatically  initialized  to 
zero.  This  initialization  isn't  necessarily  more  costly  than  aforloop 
or  memset( ) Many  compilers  easily  optimize  this  to  a very  fast 
process. 

Compile-time  constants  in  classes 

The  above  use  of  const!  s interesting  and  probably  useful  incases, 
but  it  does  not  solve  the  original  problem  which  is:  "how  do  you 
make  a compile-time  constant  inside  a class?"  The  answer  requires 
the  use  of  an  additional  keyword  which  will  not  be  fully 
introduced  until  Chapter  10:  static  The statickeyword,  in  this 
situation,  means  "there's  only  one  instance,  regardless  of  how 
many  objects  of  the  class  are  created,"  which  is  precisely  what  we 
need  here:  a member  of  a class  which  is  constant,  and  which  cannot 
change  from  one  object  of  the  cl  ass  to  another.  Thus,  a stati  c const 
of  a built-in  type  can  be  treated  as  a compile-time  constant. 

Thereisone  feature  of  static  constwhen  used  inside  classes  which 
is  a bit  unusual:  you  must  providethe  initializer  atthe  point  of 
definition  of  the  static  constThis  is  something  that  only  occurs 
with  the  static  const  as  much  as  you  might  I ike  to  use  it  in  other 
situations  it  won't  work  because  all  other  data  members  must  be 
initialized  in  theconstructor  or  in  other  member  functions. 

Here'san  example  that  shows  the  creation  and  use  of  astatic  const 
called  size  inside  a cl  ass  that  represents  a stack  of  string  pointers^: 

//:  COS : StringStack . cpp 

//  Using  static  const  to  create  a 


^Atthetimeof  this  writing,  not  all  compilers  supported  thisfeature. 
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//  compile -time  constant  inside  a class 
#include  <string> 

#include  <iostream> 
using  namespace  std; 

class  StringStack  { 

static  const  int  size  = 100; 
const  string*  stack[size]; 
int  index; 
public : 

StringStack ( ) ; 

void  push (const  string*  s); 

const  string*  pop(); 

}; 


StringStack :: StringStack ( ) : index (0)  { 

memset (stack,  0,  size  * sizeof (string*) ) ; 

} 

void  StringStack :: push (const  string*  s)  { 
if (index  < size) 

stack [ index++]  = s; 

} 

const  string*  StringStack :: pop ( ) { 

if ( index  > 0 ) { 

const  string*  rv  = stack [ — index]; 
stack [index]  = 0; 
return  rv; 

} 

return  0; 


string  iceCream[]  = { 
"pralines  & cream", 

"fudge  ripple", 

"jamocha  almond  fudge", 
"wild  mountain  blackberry", 
"raspberry  sorbet", 

"lemon  swirl", 

"rocky  road", 

"deep  chocolate  fudge" 

}; 


const  int  iCsz  = 
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sizeof  iceCream  / sizeof  *iceCream; 


int  main  ( ) { 

StringStack  ss; 
for(int  i = 0;  i < iCsz;  i++) 
ss . push ( &iceCream [ i ] ) ; 
const  string*  cp; 
while  ( (cp  = ss.popO)  !=  0) 
cout  <<  *cp  <<  endl; 

} ///:- 

Si  nee  size  is  used  to  determine  the  size  of  the  array  stack,  it  is 
indeed  a compile-time  constant,  but  one  that  is  hidden  insidethe 
class. 

N oticethat  push(  )takes  a conststring*as  an  argument,  pop( ) 
returns  a conststring*  and  StringStackholds  const  string*  If  this 
were  not  true,  you  couldn't  useaStringStackto  hold  the  pointers 
in  iceCream  However,  it  also  prevents  you  from  doing  anything 
that  will  change  the  objects  contained  by  StringStack  Of  course, 
not  all  containers  are  designed  with  this  restriction. 

The  "enum  hack"  in  old  code 

In  older  versions  of  C-H-,  staticconstwas  not  supported  inside 
classes.  This  meant  that  constwas  useless  for  constant  expressions 
inside  cl  asses.  However,  peoplestill  wanted  to  do  this  so  atypical 
solution  (usually  referred  to  asthe"enum  hack")  was  to  use  an 
untagged  enum  with  no  instances.  An  enumeration  must  have  all 
its  values  established  at  compile  time,  it'slocal  to  the  cl  ass,  and  its 
values  are  aval  I able  for  constant  expressions.  Thus,  you  will 
commonly  see: 

//:  COS : EnumHack . epp 
#include  <iostream> 
using  namespace  std; 

class  Bunch  { 

enum  { size  = 1000  }; 
int  i [size] ; 

}; 
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int  main  ( ) { 

cout  <<  "sizeof (Bunch)  = " <<  sizeof (Bunch) 

<<  ",  sizeof  (i [1000] ) = " 

<<  sizeof  ( int [ 1000 ] ) <<  endl; 

} ///:- 

The  use  of  enum  here  is  guarantee(d  to  occupy  no  storage  i n the 
object,  and  the  enumerators  are  all  evaluated  at  compile  time.  You 
can  also  explicitly  establish  the  values  of  the  enumerators: 

I enum  { one  = 1,  two  = 2,  three  }; 

With  integral  enumtypes,  thecompiler  will  continue  counting 
from  the  last  value,  so  the  enumerator  threewi  1 1 get  the  values. 

I n the  Stri ngStack.cppexampl e above,  the  line: 

I static  const  int  size  = 100; 

would  be  instead: 

I enum  { size  = 100  }; 

Although  you'll  often  see theenumtechnique  in  legacy  code,  the 
static  constfeaturewas  added  to  the  languageto  solve  just  this 
problem.  However,  there  is  no  overwhelming  reason  that  you  must 
choose  static  constDver  the  enum  hack,  and  in  this  book  the  enum 
hackisused  because  it  is  supported  by  more  compilers  at  the  time 
th I s book  was  w r I tten . 

const  objects  & member  functions 

Class  member  functions  can  be  made  const  What  does  this  mean? 

T 0 understand,  you  must  fi  rst  grasp  the  concept  of  constobjects. 

A constobject  isdefined  the  same  for  a user-defined  type  asa  built- 
in  type.  For  example: 

const  int  i = 1; 
const  blob  b (2 ) ; 
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Here,  b isaconstobjectof  typeblob.  Its  constructor  is  cal  led  with 
an  argument  of  two.  For  the  compi  ler  to  enforce  constness,  it  must 
ensurethatnodata  members  of  the  object  are  changed  during  the 
object's  lifetime.  It  can  easily  ensure  that  no  public  data  is  modified, 
but  how  is  it  to  know  which  member  functions  will  change  thedata 
and  which  ones  are  "safe"  for  a constobject? 

If  you  declare  a member  function  const  you  tell  the  compi  ler  the 
function  can  be  cal  led  for  a constobject.  A member  function  that  is 
not  specifically  declared  const!  s treated  as  one  that  will  modify 
data  members  in  an  object,  and  the  compi  ler  will  notallow  you  to 
cal  I it  for  a constobject. 

It  doesn't  stop  there,  however.  Just  claiming  a member  function  is 
constdoesn't  guarantee  it  will  act  that  way,  so  the  compi  ler  forces 
you  to  reiterate  the  constspecifi  cat!  on  when  defining  the  function. 
(Theconstbecomes  part  of  thefunction  signature,  so  both  the 
compiler  and  linker  check  for  constiess.)  Then  it  enforces constiess 
during  the  function  definition  by  issuing  an  error  message  if  you 
try  to  change  any  members  of  the  object  or  cal  I a non-constmember 
function.  Thus,  any  member  function  you  declareconstis 
guaranteed  to  behave  that  way  in  the  definition. 

To  understand  the  syntax  for  declaring  constmember  functions, 
first  notice  that  preceding  the  function  declaration  with  const 
means  the  return  value  isconst  so  that  doesn't  producethe  desired 
results.  Instead,  you  must  place  the  constspecifier  after  the 
argument  list.  For  example, 

//:  COS : ConstMember . cpp 
class  X { 
int  i ; 
public : 

X ( int  11 ) ; 
int  f ( ) const ; 

}; 


X::X(int  11)  : 1(11)  {} 

int  X::f()  const  { return  1;  } 
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int  main  ( ) { 

X xl  (10)  ; 
const  X x2  (20 ) ; 
xl.f  0 ; 
x2.f  0 ; 

} III-.- 

Note  that  the  constkeywor(d  must  be  repeated  in  the  definition  or 
the  compiler  sees  it  asadifferentfundion.  Since  f(  )isaconst 
member  function,  if  it  attempts  to  change!  in  any  way  or  to  cal  I 
another  member  function  that  is  not  const  the  compiler  flags  it  as 
an  error. 

You  can  see  that  a constmember  function  is  safe  to  call  with  both 
constand  non-constobjects.  Thus,  you  could  think  of  it  as  the  most 
general  form  of  a member  function  (and  because  of  this,  it  is 
unfortunate  that  member  functions  do  not  automatically  default  to 
const).  Any  fundion  that  doesn't  modify  member  data  should  be 
declared  as  const;  so  it  can  be  used  with  constobjeds. 

H ere's  an  example  that  contrasts  a constand  non-const  member 
fundion: 


//:  COS : Quoter . cpp 
//  Random  quote  selection 
#include  <iostream> 

#include  <cstdlib>  //  Random  number  generator 
#include  <ctime>  //  To  seed  random  generator 
using  namespace  std; 

class  Quoter  { 
int  lastquote; 
public : 

Quoter ( ) ; 

int  lastQuoteO  const; 
const  char*  quote  (); 

}; 


Quoter  : : Quoter  ( ) { 
lastquote  = -1; 

srand (time (0) ) ; //  Seed  random  number  generator 
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} 


int  Quoter : : lastQuote ( ) const  { 
return  lastquote; 

} 

const  char*  Quoter :: quote ( ) { 

static  const  char*  quotes []  = { 

"Are  we  having  fun  yet?", 

"Doctors  always  know  best", 

"Is  it  ...  Atomic?", 

"Fear  is  obscene", 

"There  is  no  scientific  evidence  " 

"to  support  the  idea  " 

"that  life  is  serious", 

"Things  that  make  us  happy,  make  us  wise", 

}; 

const  int  qsize  = sizeof  quotes/sizeof  *quotes; 
int  qnum  = rand()  % qsize; 

while ( lastquote  >=  0 &&  qnum  ==  lastquote) 
qnum  = rand()  % qsize; 
return  quotes [ lastquote  = qnum]; 

} 

int  main  ( ) { 

Quoter  q; 

const  Quoter  cq; 

cq . lastQuote ( ) ; //  OK 

//!  cq.quoteO;  //  Not  OK;  non  const  function 
for(int  i = 0;  i < 20;  iff) 
cout  <<  q. quote  0 <<  endl; 

} ///:- 

Neither  constructors  nor  destructors  can  beconstmember 
functions  because  they  virtually  always  perform  some  modification 
on  the  object  during  initialization  and  cleanup.  Thequote( ) 
member  function  also  cannot  be  const  because  it  modifies  the  data 
member  lastquote(see  the  return  statement).  However, 
lastQuote(  )makes  no  modifications,  and  so  it  can  beconstand  can 
be  safely  cal  led  for  the  constobject  cq. 
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mutable:  bitwise  vs.  logical  const 

What  if  you  want  to  create  a constmember  function,  but  you'd  stiii 
i ike  to  change  some  of  the  data  in  the  object?  This  is  sometimes 
referred  to  as  the  difference  between  b/tw/seconstand  logical  const 
(ai so  sometimes  caiied  memberwiseconsK^.  Bitwise constmeans that 
every  bit  i n the  object  is  permanent,  so  a bit  i mage  of  the  object  wi  i i 
never  change.  Logicai  constmeans  that,  aithough  the  entire  object 
is  conceptuaiiy  constant,  there  may  be  changes  on  a member-by- 
member basis.  However,  if  thecompiier  istoid  that  an  object  is 
const  itwiii  jeaiousiy  guard  that  object  to  ensure  bitwise constness. 
T 0 effect  i ogi  cai  constness,  there  are  two  ways  to  change  a data 
member  from  within  a constmember  function. 

The  first  approach  isthehistoricai  one  and  is  caiied  casting  away 
constness.  it  is  performed  in  a rather  odd  fashion.  You  takethis(the 
keyword  that  produces  the  address  of  the  current  object)  and  cast  it 
to  a pointer  to  an  object  of  the  current  type,  itwouid  seem  that  this 
isa/ready  such  a pointer.  However,  inside  a constmember  function 
it'sactuaiiy  aconstpointer,  so  by  casting  it  to  an  ordinary  pointer, 
you  remove  the  constness  for  that  operation.  Here's  an  exampie: 

//:  COS : Castaway . cpp 
//  "Casting  away"  constness 

class  Y { 
int  i ; 
public : 

Y()  ; 

void  f ( ) const ; 

}; 

Y:  :Y()  { i = 0;  } 

void  Y::f()  const  { 

//!  i++;  //  Error  — const  member  function 

( (Y* ) this ) ->i++;  //  OK:  cast  away  const-ness 
//  Better:  use  C++  explicit  cast  syntax: 

(const_cast<Y*> (this) ) ->i++; 

} 
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int  main  ( ) { 

const  Y yy; 

yy.fO;  //  Actually  changes  it! 

} III-.- 

This  approach  works  and  you'll  see  it  used  in  legacy  code,  but  it  is 
not  the  preferred  technique.  The  problenn  is  that  this  lack  of 
conslness  is  hidden  away  in  a mennber  function  definition,  and  you 
have  no  cl  ue  from  the  cl  ass  i nterface  that  the  data  of  the  object  i s 
actually  being  modified  unless  you  have  access  to  the  source  code 
(and  you  must  suspect  that  conslness  is  being  cast  away,  and  look 
for  the  cast).  To  put  everything  out  in  the  open,  you  should  use  the 
mutablekeyword  in  the  class  declaration  to  specify  that  a 
particular  data  member  may  be  changed  inside  a constobject: 

//:  COS :Mutable . cpp 
//  The  "mutable"  keyword 

class  Z { 

Int  1 ; 

mutable  Int  j; 
public : 

Z 0 ; 

void  f ( ) const ; 

}; 


Z:  :Z  0 : 1(0),  j (0)  { } 

void  Z : : f ( ) const  { 

//!  1++;  //  Error  — const  member  function 

j++;  //  OK:  mutable 

} 

Int  main  ( ) { 

const  Z zz; 

zz.fO;  //  Actually  changes  It! 

} ///:- 

This  way,  theuser  of  theclasscan  see  from  the  declaration  which 
members  are  likely  to  be  modified  in  a const  member  function. 
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ROMability 

If  an  object  is  defined  as  const;  it  is  a candidate  to  be  placed  in  read- 
only mennory  (ROM),  which  is  often  an  innportant  consideration  in 
ennbedded  systenns  programming.  Simply  making  an  object  const 
however,  i s not  enough  - the  requ i rements  for  ROM  abi  I ity  are 
much  stricter.  Of  course,  the  object  must  be  bitwise-const  rather 
than  logical-const  This  is  easy  to  see  if  logical  constiess  is 
implemented  only  through  themutablekeyword,  but  probably  not 
detectable  by  the  compiler  if  constiess  is  cast  away  inside  a const 
member  function.  In  addition, 

1.  Theclassor  structmust  have  no  user-defined  constructors  or 
destructor. 

2 . There  can  be  no  base  cl  asses  (covered  i n C hapter  14)  or 
member  objects  with  user-defined  constructors  or 
destructors. 

The  effect  of  a write  operation  on  any  part  of  a constobject  of  a 
ROMabletype  is  undefined.  Although  a suitably  formed  object 
may  be  placed  in  ROM,  no  objects  are  ever  requiredto  be  placed  in 
ROM. 


volatile 

The  sy ntax  of  volati lei s identical  to  that  for  const  but  volatile 
means  "This  data  may  change  outsidethe  knowledge  of  the 
compi  ler."  Somehow,  the  envi  ronment  i s changi  ng  the  data 
(possibly  through  multitasking,  multithreading  or  interrupts),  and 
volatiletellsthecompiler  not  to  make  any  assumptions  about  that 
data,  especially  during  optimization. 

If  the  compi  ler  says,  "I  read  thisdata  intoa  register  earlier,  and  I 
haven't  touched  that  register,"  normally  it  wouldn't  need  to  read 
thedata  again.  But  if  thedata  isvolatilothecompiler  cannot  make 
such  an  assumption  because  the  data  may  have  been  changed  by 
another  process,  and  it  must  reread  that  data  rather  than 


386 


Thinking  in  C-I--I- 


www.BruceEckel.com 


optimizing  the  codeto  remove  what  would  normally  bea 
redundant  read. 

You  create  volatileobjectsusingthesame  syntax  that  you  use  to 
create constobjects.  You  can  also  create constvolatileobjects, 
which  can't  be  changed  by  the  client  programmer  but  instead 
change  through  some  outside  agency.  Hereisan  examplethat 
might  represent  a class  associated  with  some  piece  of 
communication  hardware: 

//:  COS : Volatile . cpp 
//  The  volatile  keyword 

class  Comm  { 

const  volatile  unsigned  char  byte; 
volatile  unsigned  char  flag; 
enum  { bufsize  = 100  } ; 
unsigned  char  buf [bufsize]  ; 
int  index; 
public : 

Comm  ( ) ; 

void  isr()  volatile; 

char  read (int  index)  const; 

}; 

Comm:: Comm  0 : index (0),  byte(O),  flag(O)  {} 

//  Only  a demo;  won't  actually  work 
//  as  an  interrupt  service  routine: 
void  Comm::isr()  volatile  { 
flag  = 0; 

buf[index++]  = byte; 

//  Wrap  to  beginning  of  buffer: 
if (index  >=  bufsize)  index  = 0; 

} 

char  Comm :: read ( int  index)  const  { 
if (index  < 0 | | index  >=  bufsize) 

return  0; 

return  buf [index]; 

} 

int  main  ( ) { 
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volatile  Comm  Port; 

Port . isr ( ) ; //OK 

//!  Port . read ( 0 ) ; //  Error,  read()  not  volatile 
} ///:- 

As  with  const  you  can  usevolatilefor  data  mennbers,  mennber 
functions,  and  objects thennselves.  You  can  only  call  volatile 
mennber  functions  for  volatileobjects. 

The  reason  that  isr(  )can't  actually  be  used  as  an  interrupt  service 
routine  is  that  in  a member  function,  the  address  of  the  current 
object  (this)  must  be  secretly  passed,  and  an  ISR  generally  wants  no 
arguments  at  all.  To  solve  this  problem,  you  can  makeisr(  )a  static 
member  function,  a subject  covered  in  Chapter  10. 

The  sy ntax  of  volati lei s identical  to  const  so  discussions  of  the  two 
are  often  treated  together.  The  two  are  referred  to  in  combination  as 
the  c-v  qualifier. 


Summary 

The  const  keyword  gives  you  the  ability  to  define  objects,  function 
arguments,  return  values  and  member  functions  as  constants,  and 
to  eliminate  the  preprocessor  for  value  substitution  without  losing 
any  preprocessor  benefits.  All  this  provides  a significant  additional 
form  of  type  check!  ng  and  safety  in  your  programming.  The  use  of 
so-called  const  correctness  (the  use  of  constanyw  here  you  possibly 
can)  can  be  a I ifesaver  for  projects. 

Although  you  can  ignore  constand  continueto  use  old  C coding 
practices,  it'sthereto  help  you.  Chapters  11  and  on  begin  using 
references  heavily,  and  there  you'll  see  even  more  about  how 
critical  it  isto  useconstwith  function  arguments. 


Solutions  to  selected  exercises  can  be  found  in  the  electronic  document  TheThinking  in  C++ Annotated 
Solution  Guide,  aval  I able  for  a small  feefromwww.BruceEckel.com. 
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1.  Create  three  con  stint  values,  then  add  them  together  to 
producea  value  that  determines  the  size  of  an  array  in  an 
array  definition. Try  to  compilethe  same  codein  C and 
see  what  happens  (you  can  generally  force  your  C++ 
compiler  to  run  as  a C compiler  by  using  a command-line 
flag). 

2.  Proveto  yourself  that  the  C and  C-H-compilers  really  do 
treat  constants  differently.  Create  a global  constand  use 
it  in  a global  constant  expression;  then  compile  it  under 
both  C and  C-H-. 

3.  Create  example constdefinitions for  all  the  built-in  types 
and  their  variants.  Use  these  in  expressions  with  other 
consfeto  make  new  constdefinitions.  Makesurethey 
compile  successfully. 

4.  Create  a constdefinition  in  a header  file,  includethat 
header  file  in  two  .cpp  files,  then  compile  those  files  and 
I ink  them.  You  should  not  get  any  errors.  Now  try  the 
same  experiment  with  C. 

5.  Create  a constw  hose  value  is  determined  at  runtime  by 
reading  thetime  when  the  program  starts  (you'll  have  to 
usethe<ctime>standard  header).  Later  in  the  program, 
try  to  read  a second  value  of  the  time  into  your  constand 
see  what  happens. 

6.  Create  a constarray  of  char,  then  try  to  change  one  of  the 

chais. 

7.  Create  an  extern  constdeclaration  in  one  file,  and  put  a 
main(  )in  that  file  that  prints  the  value  of  the  extern 
const  Provide  an  extern  constdefinition  in  a second  file, 
then  compile  and  I ink  the  two  files  together. 

8.  Writetwo  poi  nters  to  constlong  using  both  forms  of  the 
declaration.  Point  one  of  them  to  an  array  of  long 
Demonstrate  that  you  can  i ncrement  or  decrement  the 
pointer,  but  you  can't  change  what  it  points  to. 

9.  Writeaconstpointertoadouble  and  point  it  at  an  array 
of  double  Show  that  you  can  changewhat  the  pointer 


8:  Constants 


389 


poi  nts  to,  but  you  can't  i ncrement  or  decrennent  the 
pointer. 

10.  Write  a constpoi  nter  to  a constobject.  Show  that  you  can 
only  read  the  value  that  the  poi  nter  poi  nts  to,  but  you 
can't  change  the  pointer  or  what  it  poi  nts  to. 

1 1 . Rennove  the  comment  on  the  error-generati  ng  I i ne  of 
code  in  PointerAssignment.cpfko  seetheerror  that  your 
compiler  generates. 

12.  Create  a character  array  literal  with  a poi  nter  that  points 
to  the  begi  nni  ng  of  the  array.  N ow  use  the  poi  nter  to 
modify  elements  in  the  array.  Does  your  compiler  report 
this  as  an  error?  Should  it?  If  it  doesn't,  why  do  you  think 
that  is? 

13.  Create  a function  that  takes  an  argument  by  value  as  a 
const  then  try  to  change  that  argument  in  the  function 
body. 

14.  Createafunction  that  takes  a floatby  value.  Insidethe 
function,  bind  a const  float&to  the  argument,  and  only 
use  the  reference  from  then  on  to  ensure  that  the 
argument  is  not  changed. 

15.  Modify  ConstReturnValues.cppemoving  comments  on 
the  error-causi  ng  I i nes  one  at  a ti  me,  to  see  what  error 
messages  your  compiler  generates. 

16.  M odify  ConstPointer.cpp'emoving  comments  on  the 
error-causi  ng  I i nes  one  at  a ti  me,  to  see  w hat  error 
messages  your  compiler  generates. 

17.  Make  a new  version  of  ConstPointer.cppcalled 
ConstReference.cppA/hich  demonstrates  references 
instead  of  pointers  (you  may  need  to  look  forward  to 
Chapter  11). 

18.  M odify  ConstTemporary.cpp'emoving  the  comment  on 
the  error-causi  ng  I i ne  to  see  what  error  messages  your 
compiler  generates. 

19.  Create  a cl  ass  containing  both  aconstand  a non-const 
float  Initializethese  using  the  constructor  initializer  list. 


390 


Thinking  in  C-I--I- 


www.BruceEckel.com 


20.  Create  a class  called  MyStringwhich  contains  a string 
and  hasa  constructor  that  initializes  thestring  and  a 
print(  )function.  Modify  StringStack.cppso  that  the 
container  holds  MyStringobjects,  and  main(  )so  it  prints 
thenn. 

21.  Createa  classcontaining  aconstmennberthatyou 
initialize  in  the  constructor  initializer  list  and  an 
untagged  enumeration  that  you  use  to  determinean 
array  size. 

22.  In  ConstM  ember.cpp  remove  the  constspecifier  on  the 
member  function  definition,  but  leave  it  on  the 
declaration,  to  see  what  kind  of  compiler  error  message 
you  get. 

23.  Createa  class  with  both  constand  non-constmember 
functions.  Create  constand  non-constobjectsof  this 
class,  and  try  cal  ling  the  different  types  of  member 
functions  for  the  different  types  of  objects. 

24.  Createa  class  with  both  constand  non-constmember 
functions.  Try  to  call  a non-constmember  function  from 
a constmember  function  to  see  what  kind  of  compiler 
error  message  you  get. 

25.  I n M utabi  e.cpp  remove  the  comment  on  the  error- 
causing  linetoseewhat  sort  of  error  message  your 
compiler  produces. 

26.  M odify  Quoter.cppby  making  quote(  )a constmember 
function  and  lastquotemutable 

27.  Createa  class  with  a volatiledata  member.  Create  both 
volatileand  non-volatilemember  functions  that  modify 
the  volatiledata  member,  and  see  what  the  compiler 
says.  Create  both  volatileand  non-volatileobjects  of 
your  cl  ass  and  try  calling  both  the  volatileand  non- 
vol ati  I emember  fu ncti ons  to  see  w hat  i s successfu I and 
what  kind  of  error  messages  the  compiler  produces. 

28.  C reate  a cl  ass  cal  I ed  bi  rd  that  can  f ly  ( ) and  a cl  ass  rock 
that  can't.  Create  a rock  object,  take  its  address,  and 
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assign  that  to  a void*.  N ow  take  the  void*  assign  it  to  a 
bird*  (you'll  have  to  use  a cast),  and  call  fiy(  )through 
that  pointer.  Is  it  clear  why  C's  permission  to  openly 
assign  viaavoid*(withoutacast)  is  a "hole"  in  the 
language,  which  couldn't  be  propagated  into  C++? 
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9:  Inline  Functions 

One  of  the  important  features  C++  inherits  from  C is 
efficiency.  If  the  efficiency  of  C++  were  dramatically 
less  than  C,  there  would  be  a significant  contingent  of 
programmers  who  couldn't  justify  its  use. 
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In  C,  one  of  the  ways  to  preserve  efficiency  is  through  the  use  of 
macros,  which  allow  you  to  make  what  looks  I ike  a function  call 
without  the  normal  function  call  overhead.  The  macro  is 
implemented  with  the  preprocessor  instead  of  the  compiler  proper, 
and  the  preprocessor  replaces  all  macro  calls  directly  with  the 
macro  code,  so  there's  no  cost  involved  from  pushing  arguments, 
making  an  assembly-language  CALL,  returning  arguments,  and 
performing  an  assembly-language  RETURN.  All  the  work  is 
performed  by  the  preprocessor,  so  you  have  the  convenience  and 
readability  of  a function  call  but  it  doesn't  cost  you  anything. 

There  are  two  problems  with  the  use  of  preprocessor  macros  in 
C-H-.  The  first  is  also  true  with  C:  a macro  looks  I ike  a function  call, 
but  doesn't  always  act  I ike  one.  This  can  bury  difficult-to-find  bugs. 
The  second  problem  is  specific  to  C-H-:  the  preprocessor  has  no 
permission  to  access  class  member  data.  This  means  preprocessor 
macros  cannot  be  used  as  class  member  functions. 

To  retain  the  efficiency  of  the  preprocessor  macro,  but  to  add  the 
safety  and  class  scoping  of  true  functions,  C-H-hasthe/n//ne 
function.  In  this  chapter,  we'll  look  at  the  problems  of  preprocessor 
macros  in  C++,  how  these  problems  are  solved  with  inline 
functions,  and  guidelines  and  insights  on  theway  inlines  work. 


Preprocessor  pitfalls 

The  key  to  the  problems  of  preprocessor  macros  is  that  you  can  be 
fooled  into  thinking  that  the  behavior  of  the  preprocessor  is  the 
sameasthebehavior  of  the  compiler.  Of  course,  it  wasintended 
that  a macro  look  and  act  I ike  a function  call,  so  it's  quite  easy  to 
fall  into  thisfiction.  The  difficulties  begin  when  the  subtle 
differences  appear. 

Asa  simple  example,  consider  the  foil  owing: 

I #define  F (x)  (x  + 1) 
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Now,  if  a call  ismadetoF  likethis 

F(l) 

the  preprocessor  expands  it,  somewhat  unexpectedly,  to  the 
following: 

(X)  (X  + 1)  (1) 

The  problem  occurs  because  of  the  gap  between  F and  its  opening 
parenthesis  in  the  macro  definition.  When  this  gap  is  removed,  you 
can  actually  call  the  macro  with  the  gap 

F (1) 

and  it  will  still  expand  properly  to 

(1  + 1) 

The  exampleaboveisfairly  trivial  and  the  problem  will  makeitself 
evident  right  away.  The  real  difficulties  occur  when  using 
expressions  as  arguments  in  macro  calls. 

There  are  two  problems.  The  first  is  that  expressions  may  expand 
insidethe  macro  so  that  their  evaluation  precedence  is  different 
from  what  you  expect.  For  example, 

#define  FLOOR(x,b)  x>=b?0:l 

Now,  if  expressions  are  used  for  the  arguments 

if (FLOOR (a&OxOf, 0x07 ) ) //  ... 

the  macro  will  expand  to 

if (a&0x0f>=0x07?0 : 1) 

The  precedence  of  & is  lower  than  that  of  >=,  so  the  macro 
evaluation  will  surprise  you.  Once  you  discover  the  problem,  you 
can  solve  it  by  putting  parentheses  around  everything  in  the  macro 
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definition.  (This  is  a good  practice  to  use  when  creating 
preprocessor  macros.)  Thus, 

#define  FLOOR(x,b)  ( (x) >= (b) ?0 : 1 ) 

Discovering  the  problem  may  be  difficult,  however,  and  you  may 
not  find  it  until  after  you've  taken  the  proper  macro  behavior  for 
granted.  In  theun-parenthesized  version  of  the  preceding  macro, 
most  expressions  will  work  correctly  becausethe  precedence  of  >= 
is  lower  than  most  of  the  operators  like  +,  /,  - -,  and  even  the 
bitwise  shift  operators.  So  you  can  easily  begin  to  think  that  it 
works  with  all  expressions,  including  those  using  bitwise  logical 
operators. 

The  preceding  problem  can  be  solved  with  careful  programming 
practice:  parenthesize  everything  in  a macro.  However,  the  second 
difficulty  is  subtler.  Unlikea  normal  function,  every  time  you  use 
an  argument  in  a macro,  that  argument  is  evaluated.  As  long  as  the 
macro  is  called  only  with  ordinary  variables,  this  evaluation  is 
benign,  but  if  the  evaluation  of  an  argument  has  side  effects,  then 
the  results  can  be  surprising  and  will  definitely  not  mi  micfunction 
behavior. 

For  example,  this  macro  determines  whether  its  argument  falls 
within  a certain  range: 

#define  BAND (x)  (((x)>5  &&  (x)<10)  ? (x)  : 0) 

As  long  as  you  use  an  "ordinary"  argument,  the  macro  works  very 
much  I ike  a real  function.  But  as  soon  as  you  relax  and  start 
believing  it /s  a real  function,  the  problems  start.  Thus: 

//:  C09 :MacroSideEf fects . cpp 
#include  ".. /require . h" 

#include  <fstream> 
using  namespace  std; 

#define  BAND (x)  (((x)>5  &&  (x)<10)  ? (x)  : 0) 
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int  main  ( ) { 

of stream  out ( "macro . out ") ; 
assure (out,  "macro . out ") ; 
for(int  i = 4;  i < 11;  1++)  { 

int  a = 1; 

out  <<  "a  = " <<  a <<  endl  <<  ' \t ' ; 

out  <<  "BAND(++a)="  <<  BAND (++a)  <<  endl; 

out  <<  "\t  a = " <<  a <<  endl; 


} ///:- 

N oti ce  the  use  of  al  I u pper-case  characters  i n the  name  of  the 
macro.  Th  i s i s a h el  pf  u I p racti  ce  becau  se  i t tel  I s th e read  er  th  i s i s a 
macro  and  not  a function,  so  if  there  are  problems,  it  acts  as  a little 
reminder. 

Here's  the  output  produced  by  the  program,  which  is  not  at  all 
what  you  would  have  expected  from  a true  function: 

a = 4 

BAND (++a) =0 
a = 5 
a = 5 

BAND (++a) =8 
a = 8 
a = 6 

BAND (++a) =9 
a = 9 
a = 7 

BAND (++a) =10 
a = 10 
a = 8 

BAND (++a) =0 
a = 10 
a = 9 

BAND (++a) =0 
a = 11 
a = 10 

BAND (++a) =0 
a = 12 

When  a isfour,  only  the  first  part  of  the  conditional  occurs,  so  the 
expression  isevaluated  only  once,  and  thesideeffect  of  the  macro 
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call  is  that  a becomes  five,  which  is  what  you  would  expect  from  a 
normal  function  call  in  the  same  situation.  However,  when  the 
number  is  within  the  band,  both  conditionals  are  tested,  which 
results  in  two  increments.  The  result  is  produced  by  evaluating  the 
argument  again,  which  results  in  a third  increment.  Once  the 
number  gets  out  of  the  band,  both  conditionals  are  still  tested  so 
you  get  two  increments.  The  side  effects  are  different,  depending 
on  the  argument. 

This  is  clearly  not  the  kind  of  behavior  you  want  from  a macro  that 
looks  I ike  a function  call.  In  this  case,  the  obvious  solution  is  to 
makeitatruefunction,  which  of  course  adds  the  extra  overhead 
and  may  reduce  efficiency  if  you  call  that  function  a lot. 
Unfortunately,  the  problem  may  not  always  be  so  obvious,  and  you 
can  unknowingly  get  a library  that  contains  functions  and  macros 
mixed  together,  so  a problem  I ike  this  can  hide  some  very  difficult- 
to-find  bugs.  For  example,  theputc(  )macro  in  cstdiomay  evaluate 
its  second  argument  twice.  This  is  specified  in  Standard  C.  Also, 
careless  implementations  of  toupper(  )as  a macro  may  evaluate  the 
argument  more  than  once,  which  will  give  you  unexpected  results 
with  toupper(*p++)^ 

Macros  and  access 

Of  course,  careful  codi  ng  and  use  of  preprocessor  macros  is 
required  with  C,  and  we  could  certainly  getaway  with  the  same 
thing  in  C++ if  it  weren't  for  one  problem:  a macro  has  no  concept 
of  the  scoping  required  with  member  functions.  The  preprocessor 
simply  performs  text  substitution,  so  you  cannot  say  something  like 

class  X { 
int  i ; 
public : 

#define  VAL(X::i)  //  Error 


^Andrew  Koenig  goes  into  moredetail  in  his  book  C Traps  & Pitfalls  (Addison- 
Wesley,  1989). 
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or  anything  even  close.  In  addition,  there  would  be  no  indication  of 
which  object  you  were  referring  to.  There  is  simply  no  way  to 
express  cl  ass  scope  in  a macro.  Without  some  alternative  to 
preprocessor  macros,  programmers  will  be  tempted  to  make  some 
data  members  publicfor  the  sake  of  efficiency,  thus  exposing  the 
underlying  implementation  and  preventing  changes  in  that 
i mpl  ementati on,  as  wel  I as  el  i mi  nati  ng  the  guard  i ng  that  private 
provides. 


I niine  functions 

In  solving  the  C++ problem  of  a macro  with  access  to  privateclass 
members,  all  the  problems  associated  with  preprocessor  macros 
were  el  i mi  nated . Thi s was  done  by  bri  ngi  ng  the  concept  of  macros 
under  the  control  of  the  compiler  where  they  belong.  C++ 
implements  the  macro  as /n//neftynct/on,  which  is  a true  function  in 
every  sense.  A ny  behavi  or  you  expect  from  an  ord  i nary  fu  ncti  on, 
you  get  from  an  inlinefunction.  The  only  difference  isthat  an  inline 
function  is  expanded  in  place,  I ike  a preprocessor  macro,  so  the 
overhead  of  the  function  call  is  eliminated.  Thus,  you  should 
(almost)  never  use  macros,  only  inline  functions. 

Any  function  defined  within  a class  body  is  automatically  inline, 
but  you  can  also  make  a non-class  function  inline  by  preceding  it 
with  theinlinekeyword.  However,  for  it  to  have  any  effect,  you 
must  includethefunction  body  with  the  declaration,  otherwise  the 
compiler  will  treat  it  as  an  ordinary  function  declaration.  Thus, 

I inline  int  plusOne(int  x)  ; 

has  no  effect  at  al  I other  than  declaring  the  function  (which  mayor 
may  not  get  an  inline  definition  sometime  later).  The  successful 
approach  provides thefunction  body: 

I inline  int  plusOne(int  x)  { return  ++x;  } 
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N otice that  the  compi ler  will  check  (as  it  always  does)  for  the 
proper  use  of  the  function  argument  list  and  return  value 
(performing  any  necessary  conversions),  something  the 
preprocessor  is  incapable  of.  Also,  if  you  try  to  w rite  the  above  as  a 
preprocessor  macro,  you  get  an  unwanted  side  effect. 

You'll  almost  always  want  to  put  inline  definitions  in  a header  file. 
When  the  compiler  sees  such  a definition,  it  puts  the  function  type 
(the  signature  combined  with  the  return  value)  and  the  function 
body  in  its  symbol  table.  When  you  use  the  function,  the  compi  ler 
checks  to  ensu re  the  cal  I is  correct  and  the  retu rn  val ue  i s bei  ng 
used  correctly,  and  then  substitutes  the  function  body  for  the 
function  cal  I , thus  el  i mi nati  ng  the  overhead . The  i nl  i ne  code  does 
occupy  space,  but  if  the  function  is  small,  this  can  actually  take  less 
space  than  the  code  generated  to  do  an  ordinary  function  call 
(pushing  arguments  on  the  stack  and  doing  theCALL). 

An  inlinefunction  in  a header  file  has  a special  status,  si  nee  you 
must  includethe header filecontainingthefuncti on  ancMts 
definition  in  every  file  where  the  function  is  used,  but  you  don't 
end  up  with  multipledefinition  errors  (however,  thedefinition 
must  be  identical  in  all  placeswherethe  inlinefunction  is 
included). 

I niines  inside  ciasses 

To  define  an  inlinefunction,  you  must  ordinarily  precedethe 
function  definition  with  theinlinekeyword.  However,  this  is  not 
necessary  insideaclassdefinition.  Any  function  you  define  insidea 
class  definition  is  automatically  an  inline.  For  example: 

//:  CO  9 : Inline . epp 
//  Inlines  inside  classes 
#include  <iostream> 

#include  <string> 
using  namespace  std; 

class  Point  { 
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int  i,  j,  k; 
public : 

PointO  : 1(0),  j(0),  k(0)  {} 

Point  (int  ii,  int  jj,  int  kk) 

: i(ii),  j(jj),  k (kk)  { } 
void  print  (const  strings  msg  = "")  const  { 
if (msg . size ( ) !=  0)  cout  <<  msg  <<  endl; 

cout  <<  "i  = " <<  i <<  ",  " 

<<  "j  = " <<  j <<  ",  " 

<<  "k  = " <<  k <<  endl; 

} 

}; 

int  main  ( ) { 

Point  p,  q ( 1 , 2 , 3 ) ; 

p .  print ( "value  of  p"); 

q .  print ( "value  of  q"); 

} ///:- 

Here,  the  two  construrtorsari(d  theprint(  )fun(lion  are  all  inlines 
by  (default.  Noticein  main(  )that  the  fart  you  are  using  inline 
functions  is  transparent,  as  it  should  be.  The  logical  behavior  of  a 
function  must  beidentical  regardless  of  whether  it'san  inline 
(otherwise  your  compiler  is  broken).  The  only  difference  you'll  see 
is  in  performance. 

Of  course,  the  temptation  isto  use  inlines  everywhere  insideci  ass 
declarations  because  they  save  you  the  extra  step  of  making  the 
external  member  function  definition.  Keep  in  mind,  however,  that 
the  idea  of  an  inline  isto  provide  improved  opportunities  for 
optimization  by  the  compiler.  But  inlining  a bigfunction  will  cause 
thatcodeto  beduplicated  everywhere  the  funrti  on  is  called, 
producing  code  bloat  that  may  mitigate  the  speed  benefit  (the  only 
rel  i abl  e cou  rse  of  arti  on  i s to  experi  ment  to  d i scover  the  effects  of 
inlining  on  your  program  with  your  compiler). 

Access  functions 

One  of  the  most  i mportant  uses  of  i nl  i nes  i nside  classes  is  the  access 
funct/on.  This  is  a small  function  that  allows  you  to  read  or  change 
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part  of  the  state  of  an  object  - that  i s,  an  i nternal  vari  abl  e or 
variables.  The  reason  inlines  are  so  i mportant  for  access  functions 
can  be  seen  in  the  foil  owing  example: 

//:  C09 : Access . cpp 
//  Inline  access  functions 

class  Access  { 
int  1 ; 
public : 

int  readO  const  { return  i;  } 
void  set (int  ii)  { i = ii;  } 

}; 


int  main  ( ) { 

Access  A; 

A. set  (100) ; 

int  X = A . read ( ) ; 

} ///:- 

H ere,  the  class  user  never  has  direct  contact  with  the  state  variables 
inside  the  class,  and  they  can  be  kept  private  under  the  control  of 
the  class  designer.  All  the  access  to  theprivatedata  members  can 
be  controlled  through  the  member  function  interface.  In  addition, 
access  is  remarkably  efficient.  Consider  the  read( ) for  example. 
Without  inlines,  the  code  generated  for  the  call  toread(  )would 
typically  include  pushing  thison  the  stack  and  making  an 
assembly  language  CALL.  With  most  machines,  the  size  of  this 
codewould  belargerthan  the  code  created  by  the  inline,  and  the 
execution  time  would  certainly  be  longer. 

Without  inline  functions,  an  efficiency-conscious  class  designer  will 
be  tempted  to  simply  makei  a public  member,  eliminating  the 
overhead  by  all  owing  the  user  to  directly  access  i.  Fromadesign 
standpoint,  this  is  disastrous  because  i then  becomes  part  of  the 
public  interface,  which  means  the  class  designer  can  never  change 
it.  You're  stuck  with  an  int  called  i.  This  is  a problem  because  you 
may  learn  sometime  later  that  it  would  be  much  more  useful  to 
represent  the  state  information  as  a floatrather  than  an  int  but 
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because  int  i is  part  of  the  public  interface,  you  can't  change  it.  Or 
you  may  want  to  perform  some  additional  calculation  as  part  of 
reading  or  setting  i,  which  you  can't  do  if  it's  public  If,  on  the 
other  hand,  you've  always  used  member  functions  to  read  and 
change  the  state  information  of  an  object,  you  can  modify  the 
underlying  representation  of  the  object  to  your  heart's  content. 

In  addition,  the  use  of  member  functions  to  control  data  members 
allows  you  to  add  code  to  the  member  function  to  detect  when  that 
data  is  being  changed,  which  can  be  very  useful  during  debugging. 
If  a data  member  is  public  anyone  can  change  it  anytime  without 
you  knowing  about  it. 

Accessors  and  mutators 

Some  peoplefurther  dividethe  concept  of  access  functions  into 
accessors  (to  read  state  information  from  an  object)  and  mutators  (to 
change  the  state  of  an  object).  In  addition,  function  overloading 
may  be  used  to  providethe  same  function  name  for  both  the 
accessor  and  mutator;  how  you  call  the  function  determines 
whether  you're  reading  or  modifying  state  information.  Thus, 

//:  CO  9 : Rectangle . cpp 
//  Accessors  & mutators 

class  Rectangle  { 
int  wide,  high; 
public : 

Rectangle ( int  w = 0,  int  h = 0) 

: wide (w) , high(h)  {} 

int  widthO  const  { return  wide;  } //  Read 
void  width (int  w)  { wide  = w;  } //  Set 
int  height  0 const  { return  high;  } //  Read 
void  height (int  h)  { high  = h;  } //  Set 

}; 


int  main  ( ) { 

Rectangle  r(19,  47); 

//  Change  width  & height: 
r. height  (2  * r.widthO); 
r.width(2  * r.heightO); 
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} III-.- 


The  constructor  uses  the  constructor  initializer  list  (briefly 
introduced  in  Chapter  8 and  covered  fully  in  Chapter  14)  to 
initializethevaluesof  wideand  high  (using  the  pseudoconstructor 
form  for  built-in  types). 

You  cannot  have  member  function  names  using  the  same 
identifiers  as  data  members,  so  you  might  be  tempted  to 
distinguish  the  data  members  with  a leading  underscore.  However, 
identifiers  with  leading  underscores  are  reserved  so  you  should  not 
use  them. 

You  may  choose  instead  to  use  "get”  and  "set"  to  indicate  accessors 
and  mutators: 

//:  CO  9 : Rectangle2 . cpp 

//  Accessors  & mutators  with  "get"  and  "set" 

class  Rectangle  { 
int  width,  height; 
public : 

Rectangle ( int  w = 0,  int  h = 0) 

: width (w),  height (h)  {} 

int  getWidthO  const  { return  width;  } 
void  setWidth(int  w)  { width  = w;  } 
int  getHeightO  const  { return  height;  } 
void  setHeight ( int  h)  { height  = h;  } 

}; 


int  main  ( ) { 

Rectangle  r(19,  47); 

//  Change  width  & height: 
r . setHeight (2  * r . getWidth ( ) ) ; 
r.setWidth(2  * r . getHeight ( ) ) ; 

} ///:- 

Of  cou  rse,  accessors  and  mutators  don't  have  to  be  si  mpl  e pi  pel  i nes 
to  an  internal  variable.  Sometimes  they  can  perform  more 
sophisticated  calculations.  The  foil  owing  example  uses  the 
Standard  C library  time  functions  to  produce  a si  mpleTimeclass: 
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//:  C09 : Cpptime . h 
//  A simple  time  class 
#ifndef  CPPTIME_H 
#define  CPPTIME_H 
#include  <ctime> 
#include  <cstring> 


class  Time  { 
std : : t ime_t  t ; 
std : : tm  local ; 
char  ascilRep [ 2 6 ] ; 
unsigned  char  Iflag,  aflag; 
void  updateLocal ( ) { 

if(!lflag)  { 

local  = *std: : localtime (&t)  ; 

If lagt+ ; 


void  updateAscii ( ) { 

if ( ! aflag)  { 
updateLocal ( ) ; 

std: : strcpy (ascilRep, std: : asctime (& local) ) ; 
af lagt+; 


public : 

Time ( ) { mark ( ) ; } 

void  mark ( ) { 

Iflag  = aflag  = 0; 
std : : time ( &t ) ; 

} 

const  char*  ascii ()  { 

updateAscii ( ) ; 
return  ascilRep; 

} 

//  Difference  in  seconds: 

int  delta (Time*  dt ) const  { 

return  int (std: : dif ftime (t,  dt->t)); 

} 

int  daylightSavings ( ) { 

updateLocal ( ) ; 
return  local . tm_isdst ; 

} 

int  dayOfYearO  { //  Since  January  1 
updateLocal  ( ) ; 
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return  local . tm_yday; 


} 

int  dayOfWeekO  { //  Since  Sunday 
updateLocal ( ) ; 
return  local . tm_wday; 

} 

int  sincel900()  { //  Years  since  1900 
updateLocal ( ) ; 
return  local . tm_year ; 

} 

int  month  0 { //  Since  January 

updateLocal ( ) ; 
return  local . tm_mon; 

} 

int  dayOfMonthO  { 
updateLocal ( ) ; 
return  local . tm_mday; 

} 

int  hourO  { //  Since  midnight,  24-hour  clock 
updateLocal ( ) ; 
return  local . tm_hour ; 

} 

int  minute  ( ) { 

updateLocal ( ) ; 
return  local . tm_min; 

} 

int  second  0 { 

updateLocal ( ) ; 
return  local . tm_sec; 


}; 

#endif  //  CPPTIME_H  ///:- 

The  Standard  C library  functions  have  multi  pie  representations  for 
time,  and  these  are  all  part  of  the  Time  cl  ass.  However,  it  isn't 
necessary  to  update  all  of  them,  so  instead  thetime_ttisused  as 
the  base  representation,  and  thetm  local  and  ASCII  character 
representation  ascilRepeach  have  flags  to  indicate  if  they've  been 
updated  tothecurrenttime_tThetwo  privatefunctions 
updateLocal(  ^nd  updateAscii(  ):heck  theflags and  conditionally 
perform  the  update. 
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The  constructor  cal  Is  the  mark(  )function  (which  the  user  can  also 
call  to  force  the  object  to  represent  the  current  time),  and  this  clears 
the  two  f I ags  to  i nd  i cate  that  the  I ocal  ti  me  and  A SC  1 1 
representation  are  now  invalid.  The ascii(  )function  calls 
updateAscii(  )which  copies  the  result  of  the  Standard  C library 
function  asctime(  )into  a local  buffer  because asctime(  )usesa 
static  data  area  that  is  overwritten  if  thefunction  is  cal  led 
elsewhere.  The  ascii  ( )function  return  value  is  the  address  of  this 
local  buffer. 

All  thefunctions starting  with  dayiightSavings(  Jjsethe 
updateLocai(  )function,  which  causes  the  resulting  composite 
inlines  to  be  fairly  large.  This  doesn't  seem  worthwhile,  especially 
considering  you  probably  won't  call  thefunctions  very  much. 
However,  this  doesn't  mean  all  the  functions  should  bemadenon- 
inline.  If  you  make  other  functions  non-inline,  at  least  keep 
updateLocai(  )nlinesothat  itscodewill  beduplicated  in  the  non- 
inline functions,  eliminating  extra  function-call  overhead. 

H ere's  a smal  I test  program: 

//:  C09 : Cpptime . cpp 
//  Testing  a simple  time  class 
#include  "Cpptime. h" 

#include  <iostream> 
using  namespace  std; 

int  main  ( ) { 

Time  start; 

for(int  i = 1;  i < 1000;  it+)  { 
cout  <<  i <<  ' ' ; 

if  (i%10  ==  0)  cout  <<  endl; 


Time  end; 
cout  <<  endl; 

cout  <<  "start  = " <<  start . ascii  () ; 
cout  <<  "end  = " <<  end.asciiO; 
cout  <<  "delta  = " <<  end . delta ( &start ) ; 
} ///:- 
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A Timeobject  is  created,  then  sometime-consuming  activity  is 
performed,  then  a second  Timeobject  is  created  to  mark  the  ending 
time.  These  are  used  to  show  starting,  ending,  and  elapsed  times. 

Stash  & Stack  with  inlines 

Armed  with  inlines,  we  can  now  convert  the  Stash  and  Stack 
cl  asses  to  be  more  effi  ci  ent: 

// : C09 : Stash4  . h 
//  Inline  functions 
#ifndef  STASH4_H 
#define  STASH4_H 
#include  ".. /require . h" 

class  Stash  { 

int  size;  //  Size  of  each  space 

int  quantity;  //  Number  of  storage  spaces 
int  next;  //  Next  empty  space 

//  Dynamically  allocated  array  of  bytes: 
unsigned  char*  storage; 
void  inflate (int  increase); 
public : 

Stash(int  sz)  : size(sz),  quantity(O), 
next(O),  storage  (0)  {} 

Stash(int  sz,  int  initQuantity)  : size(sz), 
quantity (0),  next(O),  storage (0)  { 

inflate (initQuantity)  ; 

} 

Stash : : -Stash ( ) { 

if ( storage  ! = 0 ) 
delete  [] storage; 

} 

int  add (void*  element); 
void*  fetch (int  index)  const  { 

require (0  <=  index,  "Stash :: fetch  (-) index"); 
if (index  >=  next) 

return  0;  //  To  indicate  the  end 
//  Produce  pointer  to  desired  element: 
return  &( storage [ index  * size]); 

} 

int  count  0 const  { return  next;  } 
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}; 

#endif  //  STASH4_H  ///:- 

The  small  functionsobviously  work  well  as  inlines,  but  notice  that 
the  two  largest  functions  are  still  left  as  non-inlines,  si  nee  inlining 
them  probably  wouldn't  cause  any  performance  gal  ns: 

//:  CO  9 : Stash4 . epp  {0} 

#include  "Stash4.h" 

#include  <iostream> 

#include  <cassert> 
using  namespace  std; 
const  int  increment  = 100; 

int  Stash :: add (void*  element)  { 

if  (next  >=  quantity)  //  Enough  space  left? 

inflate (increment) ; 

//  Copy  element  into  storage, 

//  starting  at  next  empty  space: 
int  startBytes  = next  * size; 
unsigned  char*  e = (unsigned  char* ) element ; 
for(int  i = 0;  i < size;  i++) 
storage [ startBytes  + i]  = e[i]; 
next++ ; 

return  (next  - 1);  //  Index  number 


void  Stash :: inf late  ( int  increase)  { 
assert (increase  >=  0); 
if (increase  ==  0)  return; 
int  newQuantity  = quantity  + increase; 
int  newBytes  = newQuantity  * size; 
int  oldBytes  = quantity  * size; 

unsigned  char*  b = new  unsigned  char [newBytes ] ; 
for (int  i = 0;  i < oldBytes;  i++) 

b[i]  = storage [i];  //  Copy  old  to  new 
delete  [] (storage);  //  Release  old  storage 
storage  = b;  //  Point  to  new  memory 
quantity  = newQuantity;  //  Adjust  the  size 
} ///:- 

Once  agai  n,  the  test  program  verif  i es  that  everyth!  ng  i s work!  ng 
correctly: 
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//:  CO  9 : Stash4Test . cpp 
//{L}  Stash4 
#include  "Stash4.h" 

#include  /require . h" 

#include  <fstream> 

#include  <iostream> 

#include  <string> 
using  namespace  std; 

int  main  ( ) { 

Stash  intStash (sizeof  (int) ) ; 
for(int  i = 0;  i < 100;  i++) 
intStash. add (&i) ; 

for (int  j = 0;  j < intStash . count  () ; j++) 

cout  <<  " intStash . fetch ( " <<  j <<  ")  = " 

<<  *( int *) intStash . fetch ( j ) 

<<  endl; 

const  int  bufsize  = 80; 

Stash  stringStash (sizeof (char)  * bufsize,  100); 
ifstream  in ( "Stash4Test . cpp" ) ; 
assure (in,  "Stash4Test . cpp" ) ; 
string  line; 

while (getline  (in,  line)) 

stringStash . add ( (char* ) line . c_str ( ) ) ; 
int  k = 0; 
char*  cp; 

while ( (cp  = (char* ) stringStash . fetch (k++) )! =0 ) 
cout  <<  " stringStash . fetch ( " <<  k <<  ")  = " 

<<  cp  <<  endl; 

} ///:- 

This  is  the  same  test  program  that  was  used  before,  so  the  output 
shouid  bebasicaiiy  thesame. 

The  Stack  ci ass  makes  even  better  use  of  iniines: 

// : C09 : Stack! . h 
//  With  inlines 
#ifndef  STACK4_H 
#define  STACK4_H 
#include  /require . h" 

class  Stack  { 
struct  Link  { 
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void*  data; 

Link*  next; 

Link (void*  dat.  Link*  nxt) : 
data(dat),  next  (nxt)  {} 

}*  head; 
public : 

Stack ( ) : head ( 0 ) { } 

-Stack ( ) { 

require (head  ==  0,  "Stack  not  empty"); 

} 

void  push (void*  dat)  { 

head  = new  Link (dat,  head); 

} 

void*  peekO  const  { 

return  head  ? head->data  : 0; 

} 

void*  pop ( ) { 

if (head  ==  0)  return  0; 
void*  result  = head->data; 

Link*  oldHead  = head; 
head  = head->next; 
delete  oldHead; 
return  result; 


}; 

#endif  //  STACK4_H  ///:- 

Notice  that  theLink(de5tructor  that  was  present  but  empty  in  the 
previous  version  of  Stack  has  been  removed.  In  pop(  1 the 
expression  delete  oldHeadsimply  releases  the  memory  used  by 
that  Link  (it  does  not  destroy  the  data  object  pointed  to  by  the 

Link). 

Most  of  thefunctions  inline  quite  nicely  and  obviously,  especially 
for  Link.  Even  pop(  )seems  legitimate,  although  anytime  you  have 
conditionals  or  local  variables  it's  not  clear  that  inlines  will  be  that 
beneficial.  Here,  the  function  is  small  enough  that  it  probably  won't 
hurt  anything. 
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If  all  yourfunctionsareinlined,  using  the  library  becomes  quite 
simple  because  there's  no  linking  necessary,  as  you  can  see  in  the 
test  example  (notice  that  there's  no  Stack4.cpF): 

//:  CO  9 : Stack4Test . cpp 
//{T}  Stack4Test . cpp 
#include  "Stack4.h" 

#include  /require . h" 

#include  <fstream> 

#include  <iostream> 

#include  <string> 
using  namespace  std; 

int  main(int  argc,  char*  argv [ ] ) { 

requireArgs (argc,  1);  //  File  name  is  argument 
ifstream  in(argv[l]); 
assure (in,  argv[l]); 

Stack  textlines; 
string  line; 

//  Read  file  and  store  lines  in  the  stack: 
while (getline (in,  line)) 

textlines . push (new  string (line) ) ; 

//  Pop  the  lines  from  the  stack  and  print  them: 
string*  s; 

while((s  = ( string* ) text lines . pop  0 ) !=  0)  { 

cout  <<  *s  <<  endl; 
delete  s; 

} 

} ///:- 

Peoplewill  sometimes  write  cl  asses  with  all  inlinefunctionssothat 
the  w hoi  e cl  ass  w i 1 1 be  i n the  header  fi  I e (you'l  I see  i n thi  s book  that 
I step  over  the  line  myself).  During  program  development  this  is 
probably  harmless,  although  sometimes  it  can  make  for  longer 
compi  lations.  Once  the  program  stabi  I izes  a bit,  you'l  I probably 
want  to  go  back  and  makefunctionsnon-inlinewhere  appropriate. 


I niines  & the  compiler 

To  understand  when  inlining  iseffective,  it's  helpful  to  know  what 
the  compiler  does  when  it  encounters  an  inline.  As  with  any 
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function,  the  compiler  holds  the  function  type  (that  is,  thefunction 
prototype  i ncl  ud  i ng  the  name  and  argu  ment  types,  i n combi  nati  on 
with  thefunction  return  value)  in  its  symbol  table.  In  addition, 
when  the  compiler  sees  that  the  inline's  function  type  andthe 
function  body  parses  without  error,  the  code  for  the  function  body 
is  also  brought  into  the  symbol  table.  Whether  the  code  is  stored  in 
source  form,  compiled  assembly  instructions,  or  some  other 
representation  is  up  to  the  compiler. 

When  you  makea  call  to  an  inlinefunction,  the  compiler  first 
ensures  that  the  cal  I can  be  correctly  made.  That  is,  all  the  argument 
types  must  either  be  the  exact  types  in  the  function's  argument  1 1st, 
or  the  compiler  must  be  able  to  make  a type  conversion  to  the 
proper  types  and  the  return  value  must  be  the  correct  type  (or 
convertible  to  the  correct  type)  in  the  destination  expression.  This, 
of  course,  isexactly  what  the  compiler  does  for  any  function  and  is 
markedly  different  from  what  the  preprocessor  does  because  the 
preprocessor  cannot  check  types  or  make  conversions. 

If  all  thefunction  type  information  fits  the  context  of  the  cal  I , then 
the  i nl  i ne  code  i s su bsti tuted  d i recti y for  the  f u ncti  on  cal  I , 
eliminating  the  cal  I overhead  and  all  owing  for  further 
optimizations  by  the  compiler.  Also,  if  the  inline  is  a member 
function,  the  address  of  the  object  (this)  is  put  in  the  appropriate 
place(s),  which  of  course  is  another  action  the  preprocessor  is 
unable  to  perform. 

Limitations 

There  are  two  situations  in  which  the  compiler  cannot  perform 
inlining.  I n these  cases,  it  simply  revertstotheordinary  formof  a 
function  by  taking  the  inline  definition  and  creating  storageforthe 
function  just  as  it  does  for  a non-i  nl  i ne.  If  it  must  do  this  i n multi  pie 
translation  units  (which  would  normally  causea  multiple 
definition  error),  the  linker  istold  to  ignore  the  multipledefinitions. 
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The  compiler  cannot  perform  inlining  if  the  function  is  too 
complicated.  This  depends  upon  the  particular  compiler,  but  at  the 
point  most  compilers  give  up,  the  inline  probably  wouldn't  gain 
you  any  efficiency.  In  general,  any  sort  of  looping  isconsidered  too 
complicated  to  expand  as  an  inline,  and  if  you  think  about  it, 
looping  probably  entails  much  more  time  inside  the  function  than 
what  is  required  for  the  function  call  overhead.  If  the  function  is 
just  a collection  of  simple  statements,  the  compiler  probably  won't 
have  any  trou bl  e i nl  i ni  ng  i t,  but  if  there  are  a I ot  of  statements,  the 
overhead  of  thefunction  call  will  be  much  less  than  the  cost  of 
executing  the  body.  And  remember,  every  ti  me  you  cal  I a big  inline 
function,  the  entire  function  body  is  inserted  in  pi  ace  of  each  call,  so 
you  can  easily  get  code  bloat  without  any  noticeable  performance 
improvement.  (Note  that  some  of  the  examples  in  this  book  may 
exceed  reasonable  i nl ine  sizes  i n favor  of  conservi ng  screen  real 
estate.) 

The  compiler  also  cannot  perform  inlining  if  the  address  of  the 
function  istaken  implicitly  or  explicitly.  If  the  compiler  must 
produce  an  address,  then  it  will  allocate  storage  for  thefunction 
codeand  use  the  resulting  address.  However,  where  an  address  is 
not  required,  the  compiler  will  probably  still  ini  ine  the  code. 

It  is  important  to  understand  that  an  inline  is  just  a suggestion  to 
the  compi  I er;  the  compi  I er  i s not  forced  to  i nl  i ne  anythi  ng  at  al  I . A 
good  compiler  will  inline  small,  simplefunctions  whileintelligently 
ignoring  inlines  that  are  too  complicated.  This  will  giveyou  the 
results  you  want-  thetrue  semantics  of  a function  call  with  the 
efficiency  of  a macro. 

Forward  references 

If  you're  imagining  what  the  compiler  is  doing  to  implement 
inlines,  you  can  confuse  yourself  into  thin  king  there  are  more 
I imitations  than  actually  exist.  In  particular,  if  an  inline  makesa 
forward  reference  to  a function  that  hasn't  yet  been  declared  in  the 
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class  (whether  that  function  is  inline  or  not),  it  can  seenn  likethe 
compiler  won't  beableto  handle  it: 


//:  C09 : EvaluationOrder . cpp 
//  Inline  evaluation  order 

class  Forward  { 
int  1 ; 
public : 

Forward ( ) : 1(0)  { } 

//  Call  to  undeclared  function: 
int  f()  const  { return  g()  + 1;  } 

int  g()  const  { return  1;  } 

}; 


int  main  ( ) { 

Forward  frwd; 
f rwd . f ( ) ; 

} ///:- 

InfO,  a call  ismadetog( ),  although  g(  )has  not  yet  been  declared. 
This  works  becausethe  language  definition  states  that  no  inline 
functions  in  a cl  ass  shall  be  evaluated  until  the  closing  brace  of  the 
class  declaration. 

Of  course,  if  g( ) in  turn  called  f( ),  you'd  end  up  with  a set  of 
recursive  cal  Is,  which  are  too  complicated  for  the  compiler  to  inline. 
(Also,  you'd  have  to  perform  some  test  in  f(  )or  g(  )to  force  one  of 
them  to  "bottom  out,"  or  the  recursion  would  be  infinite.) 

Hidden  activities  in  constructors  & destructors 

Constructors  and  destructors  are  two  places  where  you  can  be 
fooled  into  thinking  that  an  inline  is  more  efficient  than  it  actually 
is.  Constructors  and  destructors  may  have  hidden  activities, 
because  the  cl  ass  can  contain  subobjects  whose  constructors  and 
destructors  must  be  cal  led.  These  subobjects  may  be  member 
objects,  or  they  may  exist  because  of  inheritance  (covered  in 
Chapter  14).  As  an  exampleof  a class  with  member  objects: 

I //:  CO  9 : Hidden . cpp 
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//  Hidden  activities  in  inlines 
#include  <iostream> 
using  namespace  std; 

class  Member  { 
int  i,  j,  k; 
public : 

Member (int  x = 0)  : i (x) , j (x) , k(x)  {} 

~Member()  { cout  <<  "~Member"  <<  endl;  } 

}; 


class  WithMembers  { 

Member  q,  r,  s;  //  Have  constructors 
int  i ; 
public : 

WithMembers ( int  ii)  : i(ii)  {}  //  Trivial? 
~WithMembers ( ) { 

cout  <<  "~WithMembers " <<  endl; 


}; 


int  main  ( ) { 

WithMembers  wm ( 1 ) ; 

} ///:- 

The  constructor  for  Memberis  simple  enough  to  inline,  since 
there's  nothing  special  going  on  - no  inheritance  or  member  objects 
are  causing  extra  hidden  activities.  But  in  class  WithMembers 
there's  more  goi  ng  on  than  meets  the  eye.  The  constructors  and 
destructors  for  the  member  objects  q,  r,  and  sare  being  called 
automatically,  and  t/iose  constructors  and  destructors  are  also 
inline,  so  the  difference  is  significant  from  normal  member 
functions.  This  doesn't  necessarily  mean  that  you  should  always 
make  constructor  and  destructor  definitions  non-inline;  there  are 
cases  in  which  it  makes  sense.  Also,  when  you're  making  an  initial 
"sketch"  of  a program  by  quickly  writing  code,  it's  often  more 
convenient  to  use  inlines.  But  if  you're  concerned  about  efficiency, 
it's  a pi  ace  to  look. 
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Reducing  clutter 

In  a book  likethis,  the  simplicity  and  terseness  of  putting  inline 
definitions  inside  classes  is  very  useful  because  more  fits  on  a page 
or  screen  (in  a seminar).  However,  Dan  Saks^  has  pointed  out  that 
i n a real  project  thi  s has  the  effect  of  need  I essly  cl  utteri  ng  the  cl  ass 
i nterface  and  thereby  maki  ng  the  cl  ass  harder  to  use.  H e refers  to 
member  functions  defined  within  classes  using  the  Latin  in  situ  (in 
place)  and  maintains  that  all  definitions  should  be  placed  outside 
the  class  to  keep  the  interface  clean.  Optimization,  he  argues,  is  a 
separate  issue.  If  you  want  to  optimize,  usetheinlinekeyword. 
Using  this  approach,  the  earlier  Rectangle.cppexample  becomes: 

//:  CO  9 : Noinsitu . cpp 
//  Removing  in  situ  functions 

class  Rectangle  { 
int  width,  height; 
public : 

Rectangle ( int  w = 0,  int  h = 0); 
int  getWidthO  const; 
void  setWidth(int  w)  ; 
int  getHeightO  const; 
void  setHeight ( int  h)  ; 

}; 


inline  Rectangle :: Rectangle ( int  w,  int  h) 
: width (w),  height (h)  {} 

inline  int  Rectangle :: getWidth ( ) const  { 
return  width; 

} 

inline  void  Rectangle :: setWidth ( int  w)  { 
width  = w; 

} 

inline  int  Rectangle :: getHeight  ( ) const  { 
return  height; 


2 Co-author  with  Tom  Plum  of  C++  Programming  Guidelines,  Plum  Hall,  1991. 
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} 

inline  void  Rectangle :: setHeight ( int  h)  { 
height  = h; 

} 

int  main  ( ) { 

Rectangle  r(19,  47); 

//  Transpose  width  & height: 
int  iHeight  = r . getHeight ( ) ; 
r . setHeight (r . getWidth ( ) ) ; 
r . setWidth ( iHeight ) ; 

} ///:- 

Now  if  you  wanttocomparetheeffect  of  inline  functions  to  non- 
inline functions,  you  can  simply  remove  the  inlinekeyword. 

(Inline  functions  should  normally  be  put  in  header  files,  however, 
while  non-inline  functions  must  reside  in  their  own  translation 
unit.)  If  you  want  to  put  the  functions  into  documentation,  it's  a 
si mplecut-and-paste  operation.  In  situ  functions  require  more  work 
and  have  greater  potential  for  errors.  Another  argument  for  this 
approach  is  that  you  can  always  produce  a consistent  formatti  ng 
style  for  function  definitions,  something  that  doesn't  always  occur 
with  in  situ  functions. 


More  preprocessor  features 

Earlier,  I said  that  you  a/mostalways  wantto  useinlinefunctions 
instead  of  preprocessor  macros.  The  exceptions  are  when  you  need 
to  use  three  special  features  in  the  C preprocessor  (which  is  also  the 
C-H- preprocessor):  stringizing,  string  concatenation,  and  token 
pasting.  Stringizing,  introduced  earlier  in  the  book,  is  performed 
with  the#  directive  and  allows  you  to  take  an  identifier  and  turn  it 
into  a character  array.  String  concatenation  takes  place  when  two 
adjacent  character  arrays  haveno  intervening  punctuation,  in 
whi  ch  case  they  are  combi  ned . These  two  featu  res  are  especi  al  ly 
useful  when  writing  debug  code.  Thus, 

I #define  DEBUG (x)  cout  <<  #x  " = " <<  x <<  endl 
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This  prints  the  value  of  any  variable.  You  can  also  get  a trace  that 
pri  nts  out  the  statements  as  they  execute: 

I #define  TRACE (s)  cerr  <<  #s  <<  endl;  s 

The  #sstringizes  the  Statement  for  output,  and  the  second  s 
reiterates  the  statement  so  it  is  executed.  Of  course,  this  kind  of 
thing  can  cause  problems,  especially  in  one-line  for  I oops: 

for(int  i = 0;  i < 100;  i++) 

TRACE ( f ( i ) ) ; 

Because  there  are  actually  two  statements  in  theT  RAC  E(  )macro, 
the  one-l  i ne  f or  I oop  executes  on  I y the  f i rst  one.  The  sol  uti  on  i s to 
replace  the  semi  col  on  with  a comma  in  the  macro. 

Token  pasting 

Token  pasting,  implemented  with  the##  directive,  is  very  useful 
when  you  are  manufacturing  code.  Itallowsyou  totaketwo 
identifiers  and  paste  them  together  to  automatically  create  a new 
identifier.  For  example, 

#define  FIELD  (a)  char*  a##_string;  int  a##_size 
class  Record  { 

FIELD (one) ; 

FIELD (two) ; 

FIELD (three) ; 

//  . . . 

}; 

Each  call  to  the  FI  ELD  ( )macro  creates  an  identifier  to  hold  a 
character  array  and  another  to  hold  the  length  of  that  array.  N ot 
only  is  it  easier  to  read,  it  can  eliminate  coding  errors  and  make 
mai  ntenance  easi  er. 
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I mproved  error  checking 

The  require.hfunctions  have  been  used  up  to  this  point  without 
defining  thenn  (although  assert(  )hasalso  been  used  to  help  detect 
programmer  errors  where  it's  appropriate).  Now  it's  time  to  define 
this  header  file.  Inlinefunctions  are  convenient  here  because  they 
allow  everything  to  be  placed  in  a header  file,  which  simplifies  the 
process  of  using  the  package.  You  just  include  the  header  file  and 
you  don't  need  to  worry  about  linking  an  implementation  file. 

You  should  notethat  exceptions  (presented  in  detail  in  Volume  2 of 
this  book)  providea  much  more  effective  way  of  handling  many 
kinds  of  errors  - especially  those  that  you'd  I ike  to  recover  from - 
instead  of  just  halting  the  program.  The  conditions  that  require.h 
handles,  however,  are  ones  which  prevent  the  continuation  of  the 
program,  such  asif  the  user  doesn't  provide  enough  command-line 
arguments  or  if  afilecannot  be  opened.  Thus,  it's  acceptable  that 
they  call  the  Standard  C Library  function  exit( ) 

The fol I ow i ng  head er  f i I e i s placed  i n the  book's  root  d i rectory  so 
it's  easily  accessed  from  all  chapters. 

/ / : : require  . h 

//  Test  for  error  conditions  in  programs 

//  Local  "using  namespace  std"  for  old  compilers 

#ifndef  REQUIRE_H 

#define  REQUIRE_H 

#include  <cstdio> 

#include  <cstdlib> 

#include  <fstream> 

#include  <string> 

inline  void  require (bool  requirement, 

const  std::string&  msg  = "Requirement  failed") { 
using  namespace  std; 
if  (! requirement ) { 

fputs (msg . c_str ( ) , stderr) ; 
fputs("\n",  stderr); 
exit  ( 1 ) ; 

} 
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} 


inline  void  requireArgs ( int  argc,  int  args, 
const  std:: Strings  msg  = 

"Must  use  %d  arguments")  { 
using  namespace  std; 
if  (argc  !=  args  + 1)  { 

fprintf (stderr,  msg.c_str(),  args); 
fputs("\n",  stderr); 
exit  ( 1 ) ; 


inline  void  requireMinArgs ( int  argc,  int  minArgs, 
const  std:: Strings  msg  = 

"Must  use  at  least  %d  arguments")  { 
using  namespace  std; 
if (argc  < minArgs  + 1)  { 

fprintf (stderr,  msg.c_str(),  minArgs); 
fputs("\n",  stderr); 
exit ( 1 ) ; 


inline  void  assure (std: : if streams  in, 
const  std::stringS  filename  = "")  { 

using  namespace  std; 
if ( ! in)  { 

fprintf (stderr,  "Could  not  open  file  %s\n", 
filename . c_str ( ) ) ; 
exit ( 1 ) ; 


inline  void  assure (std: : of streams  out, 
const  std::stringS  filename  = "")  { 

using  namespace  std; 
if ( ! out ) { 

fprintf (stderr,  "Could  not  open  file  %s\n", 
filename . c_str  ( ) ) ; 
exit  ( 1 ) ; 

} 

} 

#endif  //  REQUIRE_H  ///:- 
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The  default  values  provide  reasonable  messages  that  can  be 
changed  if  necessary. 


You'll  notice  that  instead  of  using  char*  arguments,  const  string& 
arguments  are  used.  This  allows  both  char* and  string  as 
arguments  to  these  functions,  and  thus  is  more  generally  useful 
(you  may  want  to  follow  this  form  in  your  own  coding). 

In  thedefinitionsfor  requireArgs(  ^nd  requireMinArgs(,)oneis 

added  to  the  number  of  arguments  you  need  on  the  command  line 
because  argc  always  includes  the  name  of  the  program  being 
executed  as  argument  zero,  and  so  always  has  a value  that  is  one 
more  than  thenumber  of  actual  arguments  on  the  command  line. 

Notethe  use  of  local  "using  namespace  std  declarations  within 
each  fu net! on.  Thi s I s because  some  compi  I ers  at  the  ti  me  of  thi s 
writing  incorrectly  did  not  include  the  C standard  library  functions 
in  namespace  std  so  explicit  qualification  would  cause  a compile- 
time error.  The  local  declaration  allowsrequire.hto  work  with  both 
correct  and  incorrect  libraries  without  opening  up  the  namespace 
std  for  anyone  who  includes  this  header  file. 

H ere's  a si  mple  program  to  test  require.h 

//:  CO  9 : ErrTest . epp 
//{T}  ErrTest. epp 
//  Testing  require.h 
#include  "../require.h" 

#include  <fstream> 
using  namespace  std; 

int  main(int  argc,  char*  argv [ ] ) { 

int  i = 1; 

require  (i,  "value  must  be  nonzero"); 
requireArgs (argc,  1); 
requireMinArgs (argc,  1); 
ifstream  in(argv[l]); 

assure  (in,  argv[l]);  //  Use  the  file  name 
ifstream  nof ile ( "nofile . xxx" ) ; 

//  Fails: 
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//!  assure  (nofile) ; //  The  default  argument 
ofstream  out ( "tmp . txt " ) ; 
assure (out ) ; 

} III-.- 

You  might  be  tempted  to  go  one  step  further  for  opening  files  and 
add  a macro  to  require.h 

#define  IFOPEN (VAR,  NAME)  \ 
if stream  VAR (NAME)  ; \ 

assure (VAR,  NAME) ; 

Which  could  then  be  used  likethis: 

IFOPEN(in,  argv[l]) 

A t f i rst,  thi  s mi  ght  seem  appeal  i ng  si  nee  it  means  there's  I ess  to 
type.  It's  not  terribly  unsafe,  but  it'sa  road  best  avoided.  Note  that, 
once  again,  a macro  looks  I ike  a function  but  behaves  differently; 
it's  actually  creating  an  object  (in)  whose  scope  persists  beyond  the 
macro.  You  may  understand  this,  but  for  new  programmers  and 
code  mai  ntai  ners  it's  just  one  more  thi  ng  they  have  to  puzzi  e out. 
C++ is  complicated  enough  without  adding  to  the  confusion,  so  try 
to  tal  k yourself  out  of  usi  ng  preprocessor  macros  whenever  you 
can. 


Summary 

It'scritical  that  you  beableto  hidethe  underlying  implementation 
of  a class  because  you  may  want  to  change  that  i mplementation 
sometime  later.  You'll  make  these  changes  for  efficiency,  or  because 
you  get  a better  understanding  of  the  problem,  or  because  some 
new  class  becomes  aval  I able  that  you  want  to  use  in  the 
i mpl  ementati  on . A nyth  i ng  that  jeopard  i zes  the  pri  vacy  of  the 
underlying  implementation  reduces  the  flexibility  of  the  language. 
Thus,  the  inline  function  is  very  important  because  it  virtually 
eliminates  the  need  for  preprocessor  macros  and  their  attendant 
problems.  With  inlines,  member  functions  can  be  as  efficient  as 
preprocessor  macros. 


9:  I niine  Functions 


423 


The  inline  function  can  be  overused  in  class  definitions,  of  course. 
The  programmer  istempted  to  do  so  because  it's  easier,  so  it  will 
happen.  However,  it's  not  that  big  of  an  issue  because  later,  when 
looking  for  size  reductions,  you  can  always  change  the  functions  to 
non-ini  ines  with  no  effect  on  thei  r functional  ity.  The  development 
guideline  should  be  "First  make  it  work,  then  optimize  it." 


Exercises 

Solutions  to  selected  exercises  can  be  found  in  the  electronic  document  TheThinking  in  C++ Annotated 
Solution  Guide,  aval  I able  for  a small  feefromwww.BruceEckel.com. 

1.  Write  a program  that  uses  the  F( ) macro  shown  at  the 
beginning  of  the  chapter  and  demonstrates  that  it  does 
not  expand  properly,  as  described  in  the  text.  Repair  the 
macro  and  show  that  it  works  correctly. 

2.  Writea  program  that  uses  the  FLO  0R(  )macro  shown  at 
the  beginning  of  the  chapter.  Show  the  conditions  under 
which  it  does  not  work  properly. 

3.  M odify  M acroSideEffects.cppo  that  BAN  D ( )works 
properly. 

4.  Create  two  identical  functions,  fl()andf2()ilnlinefl() 
and  Ieavef2(  )asan  non-inline  function.  Use  the 
Standard  C Library  function  clock(  )that  is  found  in 
<ctime>to  mark  the  starting  point  and  ending  points 
and  comparethetwo  functions  to  see  which  one  is  faster. 
You  may  need  to  make  repeated  cal  Is  to  the  functions 
insideyourtiming  loop  in  order  to  get  useful  numbers. 

5.  Experiment  with  the  size  and  complexity  of  the  code 
inside  the  functions  in  Exercise  4 to  see  if  you  can  find  a 
break-even  point  where  the  inline  function  and  the  non- 
ini  ine  function  take  the  same  amount  of  time.  If  you  have 
them  available,  try  this  with  different  compilers  and  note 
the  differences. 

6.  Provethat  inlinefunctionsdefauitto  internal  linkage. 
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7.  Create  a cl  ass  that  contains  an  array  of  char.  Add  an 
inline  constructor  that  uses  the  Standard  C library 
function  memset(  )to  initialize  the  array  to  the 
constructor  argument  (default  this  to ' '),  and  an  inline 
member  function  called  print(  )to  print  out  all  the 
characters  in  the  array. 

8 . T ake  the  N estFri  end  .cppexamp  I e from  C hapter  Sand 
replace  all  the  member  functions  with  inlines.  Makethem 
non-in  situ  inlinefunctions.  Also  change theinitialize( ) 
functions  to  constructors. 

9.  M odify  StringStack.cppfrom  Chapter  8 to  use  inline 
functions. 

10.  Create  an  enum  called  Huecontaining  red,  blue  and 
yel  I ow.  N ow  create  a cl  ass  cal  I ed  C ol  or  contai  n i ng  a d ata 
member  of  type  H ue  and  a constructor  that  sets  the  Hue 
from  its  argument.  Add  access  functions  to  "get"  and 
"set"  the  Hue  Make  all  of  the  functions  inlines. 

11.  Modify  Exercise  lOto  use  the  "accessor"  and  "mutator" 
approach. 

12.  Modify  Cpptime.cppso  that  it  measures  the  time  from 
the  ti  me  that  the  program  begi  ns  ru  nni  ng  to  the  ti  me 
when  the  user  presses  the  "Enter"  or  "Return"  key. 

13.  Create  a class  with  two  inline  member  functions,  such 
that  the  first  function  that's  defined  in  the  cl  ass  cal  Is  the 
second  function,  without  the  need  for  a forward 
declaration.  Write  a main  that  creates  an  object  of  the 
class  and  cal  Is  the  first  function. 

14.  CreateaclassA  with  an  inlinedefaultconstructorthat 
announces  itself.  Now  make  a new  cl  ass  B and  put  an 
object  of  A as  a member  of  B,  and  giveB  an  inline 
constructor.  Create  an  array  of  B objects  and  see  what 
happens. 

15.  Create  a large  quantity  of  the  objects  from  the  previous 
Exercise,  and  usetheTimeclasstotimethedifference 
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between  non-inline  constructors  and  inline  constructors. 
(If  you  have  a profiler,  also  try  using  that.) 

16.  Write  a program  that  takes  a stringas  the  command-1  i ne 
argument.  Write  a for  loop  that  removes  one  character 
from  thestringwith  each  pass,  and  usetheDEBUG( ) 
macro  from  this  chapter  to  print  the  string  each  time. 

17.  Correct  theTRAC  E(  )macro  as  specified  in  this  chapter, 
and  prove  that  it  works  correctly. 

18.  Modify  the  FI  ELD  ( )macro  so  that  it  also  contains  an 
i ndex  n u mber.  C reate  a cl  ass  w hose  members  are 
composed  of  cal  Is  to  the  FI  ELD  ( )macro.  Add  a member 
function  that  allowsyou  to  look  up  afield  using  its  index 
number.  Write  a main ( )to  test  the  class. 

19.  Modify  the  FI  ELD  ( )macro  so  that  it  automatically 
generates  access  fu ncti  ons  for  each  fi  el d (the  data  shou I d 
sti  1 1 be  pri  vate,  however).  C reate  a cl  ass  w hose  members 
are  composed  of  cal  Is  to  the  FI  ELD  ( )macro.  Write  a 
main(  )to  test  the  cl  ass. 

20.  Write  a program  that  takes  two  command-line 
arguments:  the  first  is  an  inland  the  second  is  a file 
name.  U serequ  I re.hto  ensure  that  you  havethe  right 
numberof  arguments,  that theintisbetween  Sand  10, 
and  that  the  file  can  successfully  be  opened. 

21.  WriteaprogramthatusesthelFOPEN(  )macrotoopen 
afileasan  input  stream.  Note  the  creation  of  the  ifstream 
object  and  its  scope. 

22.  (Challenging)  Determine  how  to  get  your  compiler  to 
generate  assembly  code.  Create  a file  containing  a very 
small  function  and  amain(  )that  cal  Is  the  function. 
Generate  assembly  code  when  thefunction  isinlined  and 
not  inlined,  and  demonstrate  that  the  inlined  version 
does  not  have  thefunction  call  overhead. 
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10:  Name  Control 

Creating  names  is  a fundamental  activity  in 
programming,  and  when  a project  gets  large,  the 
number  of  names  can  easily  be  overwhelming. 
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C++ allows  you  a great  deal  of  control  over  the  creation  and 
visibility  of  names,  where  storage  for  those  names  is  placed,  and 
linkage  for  names. 

The  static  keyword  was  overloaded  in  C before  people  knew  what 
the  term  "overload"  meant,  and  C++ has  added  yet  another 
meaning.  The  underlying  concept  with  all  uses  of  static  seems  to  be 
"something  that  holds  its  position"  (I  ike  static  electricity),  whether 
that  means  a physical  location  in  memory  or  visibility  within  a file. 

In  this  chapter,  you'll  learn  how  staticcontrols  storage  and 
visibility,  and  an  improved  way  to  control  access  to  names  via 
C++'snamespacefeature.  You'll  also  find  out  how  to  use  functions 
that  were  written  and  compiled  in  C. 


Static  elements  from  C 

In  both  C and  C++ the  keyword  statichastwo  basic  meanings, 
which  unfortunately  often  step  on  each  other's  toes: 

1 . All  ocated  once  at  a fi xed  add  ress;  that  i s,  the  object  i s created 

i n a speci  al  static  data  area  rather  than  on  the  stack  each  ti  me  a 
functi  on  i s cal  I ed . Thi  s i s the  concept  of  static  storage. 

2.  Local  to  a particular  translation  unit  (and  local  to  a class 
scope  i n C ++,  as  you  w i 1 1 see  I ater) . H ere,  stati c control  s the 
i//s/ib/7/ty  of  a name,  so  that  name  cannot  be  seen  outside  the 
transi  ati  on  u nit  or  cl  ass.  Thi  s al  so  descri  bes  the  concept  of 
//nkage,  which  determines  what  names  thelinkerwill  see. 

Thissection  will  lookattheabovemeaningsof  stati cas they  were 
inherited  from  C. 

Static  variables  inside  functions 

When  you  create  a local  variable  inside  a function,  the  compiler 
al  I ocates  storage  for  that  vari  abl  e each  ti  me  the  f u ncti  on  i s cal  I ed  by 
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moving  the  stack  pointer  down  an  appropriate  amount.  If  there  is 
an  initializer  for  the  variable,  theinitialization  isperformed  each 
ti  me  that  sequence  poi  nt  i s passed . 

Sometimes,  however,  you  want  to  retain  a value  between  function 
calls.  You  could  accomplish  this  by  making  a global  variable,  but 
then  that  variable  would  not  be  under  the  sole  control  of  the 
function.  C and  C++ allow  you  to  createastaticobject  inside  a 
function;  the  storage  for  this  object  is  not  on  the  stack  but  instead  in 
the  program's  static  data  area.  This  object  is  initialized  only  once, 
the  first  time  the  function  iscalled,  and  then  retains  its  value 
between  function  invocations.  For  example,  thefollowing  function 
returns  the  next  character  in  the  array  each  time  the  function  is 
called: 

// : CIO : StaticVariablesInfunctions . cpp 
#include  ".. /require . h" 

#include  <iostream> 
using  namespace  std; 

char  oneChar (const  char*  charArray  = 0)  { 

static  const  char*  s; 
if (charArray)  { 
s = charArray; 
return  *s; 

} 

else 

require (s,  "un-initialized  s"); 
if  (*s  ==  ' \0 ' ) 
return  0; 
return  *s++; 

} 

char*  a = "abcdefghi jklmnopqrstuvwxyz"; 
int  main  ( ) { 

//  oneCharO;  //  require  ()  fails 
oneChar(a);  //  Initializes  s to  a 
char  c; 

while  ( (c  = oneCharO)  !=  0) 
cout  <<  c <<  endl; 
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} III-.- 


The  static  char*  ^olds  its  value  between  callsof  oneChar( ) 
because  its  storage  is  not  part  of  the  stack  frame  of  the  fu ncti on,  but 
is  i n the  static  storage  area  of  the  program.  When  you  cal  I 
oneChar(  )with  a char* argument,  s is  assigned  to  that  argument, 
and  the  first  character  of  the  array  is  returned.  Each  subsequent  call 
to  oneChar(  )without  an  argument  produces  the  default  value  of 
zeroforcharArray  which  indicates  to  the  function  that  you  are  still 
extracting  characters  from  the  previously  initialized  valueof  s.The 
function  will  continue  to  produce  characters  until  it  reaches  the  null 
terminator  of  the  character  array,  at  which  poi  nt  it  stops 
incrementing  the  pointer  so  it  doesn't  overrun  the  end  of  the  array. 

But  what  happens  if  you  call  oneChar(  )with  no  arguments  and 
without  previously  initializing  the  value  of  s?  In  the  definition  for  s, 
you  could  have  provided  an  initializer, 

static  char*  s = 0; 

but  if  you  do  not  provide  an  initializerfor  a static  variable  of  a 
bui  It-i  n type,  the  compi  ler  guarantees  that  variable  wi  1 1 be 
initialized  to  zero  (converted  to  the  proper  type)  at  program  start- 
up. So  in  oneChar( ) the  first  time  the  function  iscalled,  s iszero. 

In  this  case,  the  if(!s)conditional  will  catch  it. 

The  initialization  abovefor  s is  very  simple,  but  initialization  for 
static  objects  (I  i ke  al  I other  objects)  can  be  arbitrary  expressions 
involving  constants  and  previously  declared  variables  and 
functions. 

You  should  be  aware  that  the  function  above  is  very  vulnerable  to 
multithreading  problems;  whenever  you  design  functions 
containing  static  variables  you  should  keep  multithreading  issues 
in  mind. 
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static  class  objects  inside  functions 

The  rules  are  the  same  for  static  objects  of  user-defined  types, 
i ncl  ud  i ng  the  fact  that  some  i niti  al  izati  on  i s requ  i red  for  the  object. 
H owever,  assignment  to  zero  has  meani  ng  only  for  bui  It-i  n types; 
user-defined  types  must  deinitialized  with  constructor  calls. Thus, 
if  you  don't  specify  constructor  arguments  when  you  define  the 
static  object,  the  class  must  have  a default  constructor.  For  example, 

// : CIO : StaticOb jectsInFunctions . cpp 
#include  <iostream> 
using  namespace  std; 

class  X { 
int  i ; 
public : 

X(int  11  = 0)  : 1(11)  {}  //  Default 

~X  ( ) { cout  <<  "X::~XO"  <<  endl;  } 

}; 


void  f ( ) { 

static  X xl (47) ; 

static  X x2;  //  Default  constructor  required 

} 

int  main  ( ) { 

f 0 ; 

} ///:- 

The  Static  objects  of  type  X insidef(  )can  deinitialized  either  with 
the  constructor  argument  list  or  with  the  default  constructor.  This 
construction  occurs  the  first  time  control  passes  through  the 
definition,  and  only  the  first  time. 

Static  object  destructors 

Destructors  for  static  objects  (that  is,  all  objects  with  static  storage, 
not  just  local  static  objects  as  in  the  example  above)  are  called  when 
main(  jexitsorwhen  the  Standard  C library  function  exit(  )is 
explicitly  called.  In  most  implementations,  main(  )just  callsexit( ) 
when  itterminates.  This  means  that  it  can  be  dangerous  to  call 
exitO  inside  a destructor  because  you  can  end  up  with  infinite 
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recursion.  Static  object  destructors  are  not  called  if  you  exit  the 
program  using  the  Standard  C library  function  abort( ) 


You  can  specify  actionsto  take  place  when  leaving  main(  )(or 
calling  exit(  D by  using  the  Standard  C library  function  atexit( ) In 
this  case,  the  functions  registered  by  atexit(  )may  be  cal  led  before 
the  destructors  for  any  objects  constructed  before  leaving  main( ) 
(or  calling  exit(  |. 

Like  ordinary  destruction,  destruction  of  static  objects  occurs  in  the 
reverse  order  of  initialization.  However,  only  objects  that  have  been 
constructed  are  destroyed.  Fortunately,  the  C-H-development  tools 
keep  track  of  initialization  order  and  the  objects  that  have  been 
constructed.  Global  objects  are  always  constructed  before  main ( )is 
entered  and  destroyed  asmain(  )exits,  but  if  a function  containing 
a local  static  object  is  never  called,  the  constructor  for  that  object  is 
never  executed,  so  the  destructor  is  also  not  executed.  For  example, 

//:  CIO : StaticDestructors . cpp 
//  Static  object  destructors 
#include  <fstream> 
using  namespace  std; 

ofstream  out ( " statdest . out " ) ; //  Trace  file 

class  Obj  { 

char  c;  //  Identifier 
public : 

Obj  (char  cc)  : c(cc)  { 

out  <<  "Obj::ObjO  for  " <<  c <<  endl; 

} 

~Obj()  { 

out  <<  "Obj::~ObjO  for  " <<  c <<  endl; 


}; 


Obj  a ('a');  //  Global  (static  storage) 

//  Constructor  & destructor  always  called 

void  f ( ) { 

static  Obj  b ( ' b ' ) ; 

} 
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void  g()  { 

static  Ob j c ( ' c ' ) ; 

} 

int  main  ( ) { 

out  <<  "inside  main()"  <<  endl; 

f();  //  Calls  static  constructor  for  b 

//  g()  not  called 

out  <<  "leaving  main()"  <<  endl; 

} ///:- 

InObj,  thechar  cactsasan  identifier  so  the  constructor  and 
destructor  can  print  out  information  about  the  object  they're 
working  on.TheObj  aisaglobal  object,  so  the  constructor  is 
always  cal  led  for  it  before  main(  )is  entered,  but  the  constructors 

forthestatic  Obj  binsidef(  )and  thestatic  Obj  dnsideg(  )are 

called  only  if  those  functions  are  called. 

To  demonstrate  which  constructors  and  destructors  are  cal  led,  only 
f( ) is  cal  led.  The  output  of  the  program  is 

Ob j : : Ob j ( ) for  a 
inside  main  ( ) 

Ob j : : Ob j ( ) for  b 
leaving  main ( ) 

Ob j : : -Obj ( ) for  b 
Ob j : : -Obj ( ) for  a 

Theconstructorfor  a iscalled  before main(  )is  entered,  and  the 
constructor  for  b iscalled  only  because  f( ) is  called.  When  main( ) 
exits,  the  destructors  for  the  objects  that  have  been  constructed  are 
called  in  reverse  order  of  their  construction.  This  means  that  if  g( ) 
/s  called,  the  order  in  which  thedestructorsfor  b and  care  cal  led 
depends  on  whether  f(  )or  g(  )iscalled  first. 

N oti  ce  that  the  trace  f i I e of  stream  object  out  I s al  so  a stati  cobject- 
since  it  is  defined  outsideof  all  functions,  it  lives  in  thestatic 
storage  area.  It  is  important  that  its  definition  (as  opposed  to  an 
extern  declaration)  appear  at  the  beginning  of  the  file,  before  there 
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is  any  possible  use  of  out  Otherwise,  you'll  be  using  an  object 
before  it  is  properly  initialized. 

In  C++,  theconstructorfor  a global  static  object  is  cal  led  before 
main(  )isentered,  so  you  now  have  a simple  and  portableway  to 
execute  code  before  enter!  ng  main(  )and  to  execute  code  with  the 
destructor  after  exiting  main( ) In  C,  this  was  always  a trial  that 
required  you  to  root  around  in  the  compiler  vendor's  assembly- 
language  startup  code. 

Controlling  linkage 

Ordinarily,  any  name  at  f/7e scope  (that  is,  not  nested  inside  a class 
or  function)  is  visiblethroughout  all  translation  units  in  a program. 
Thisisoften  called  external  linkage  because  at  I ink  time  the  name  is 
visibleto  the  linker  everywhere,  external  to  that  translation  unit. 
Global  variables  and  ordinary  functions  have  external  linkage. 

There  are  times  when  you'd  liketo  limit  the  visibility  of  a name. 

Y ou  mi  ght  I i ke  to  have  a vari  abl  e at  f i I e scope  so  al  I the  f u ncti  ons  i n 
thatfilecan  useit,  but  you  don't  want  functions  outsidethatfileto 
see  or  access  that  variable,  or  to  inadvertently  cause  name  clashes 
with  identifiers outsidethe file. 

A n object  or  f u ncti  on  name  at  f i I e scope  that  i s expl  i ci  tl  y deci  ared 
staticis  local  to  its  translation  unit  (in  thetermsof  this  book,  the 
cpp  file  where  the  declaration  occurs).  That  name  has /n  tern  a/ 
//nkape.  This  means  that  you  can  use  the  same  name  in  other 
translation  units  without  a name  clash. 

One  advantage  to  internal  linkage  is  that  the  name  can  be  placed  in 
a head  er  f i I e w i thout  worry!  ng  that  there  w i 1 1 be  a cl  ash  at  I i nk 
time.  Names  that  are  commonly  placed  in  header  files,  such  as 
constdefinitionsand  inlinefunctions,  defauitto  internal  linkage. 
(However,  constdefaultsto  internal  linkage  only  in  C-H-;  in  C it 
defaults  to  external  linkage.)  Note  that  linkage  refers  only  to 
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dements  that  have  addresses  at  link/  load  time;  thus,  class 
declarations  and  local  variables  have  no  linkage. 

Confusion 

Here's  an  example  of  how  the  two  meanings  of  staticcan  crossover 
each  other.  All  global  objects  implicitly  have  static  storage  class,  so 
if  you  say  (at  file  scope), 

int  a = 0; 

then  storage  for  a will  be  in  the  program's  static  data  area,  and  the 
initialization  for  a will  occur  once,  before main(  )isentered.  In 
addition,  the  visibility  of  a is  global  across  all  translation  units.  In 
terms  of  visibility,  theoppositeof  static(visibleonly  in  this 
translation  unit)  isextern  which  explicitly  states  that  the  visibility 
of  the  name  is  across  all  translation  units.  So  the  definition  aboveis 
equivalent  to  saying 

extern  int  a = 0; 

But  if  you  say  instead, 

static  int  a = 0; 

all  you'vedone  is  change  the  visibility,  so  a has  internal  linkage. 
The  storage  cl  ass  i s u nchanged  - the  object  resi  des  i n the  stati  c data 
area  whether  the  visibility  isstaticor  extern. 

Once  you  get  into  local  variables,  staticstops  altering  the  visibility 
and  i nstead  alters  the  storage  cl  ass. 

If  you  declare  what  appears  to  be  a local  variable  as  exteri\  it 
means  that  the  storage  exi  sts  el  sew  here  (so  the  vari  abl  e i s actual  I y 
global  to  the  function).  For  example: 

//:  CIO : LocalExtern . cpp 
//{L}  LocalExtern2 
#include  <iostream> 

int  main  ( ) { 
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extern  int  i; 
std : : cout  <<  i ; 

} III-.- 

1 1 \ CIO : LocalExtern2 . cpp  {0} 
int  i = 5; 

///:- 

With  function  names  (for  non-member  functions),  staticand  extern 
can  only  alter  visibility,  so  if  you  say 

I extern  void  f(); 

it's  the  same  as  the  unadorned  declaration 

I void  f ( ) ; 

and  if  you  say, 

I static  void  f ( ) ; 

it  means  f(  )isvisibleonly  within  this  translation  unit-  this  is 
someti  mes  cal  I ed  file  static. 

Other  storage  class  specifiers 

You  will  see  staticand  externused  commonly.  There  are  two  other 
storage  cl  ass  specifiers  that  occur  less  often.  The  auto  specifier  is 
al  most  never  used  because  it  tel  I s the  compi  I er  that  this  is  a local 
variable,  auto  is  short  for  "automatic"  and  it  refers  to  the  way  the 
compiler  automatically  allocates  storage  for  the  variable.  The 
compiler  can  always  determine  this  fact  from  the  context  in  which 
the  variable  is  defined,  so  auto  is  redundant. 

A registervariableisa  local  (auto)  variable,  along  with  a hint  to  the 
compiler  that  thisparticularvariablewill  be  heavily  used  so  the 
compiler  ought  to  keep  it  in  aregister  if  itcan.Thus,  it  is  an 
optimization  aid.  Various  compilers  respond  differently  to  this 
hint;  they  have  the  option  to  ignore  it.  If  you  take  the  address  of  the 
vari  abl  e,  the  regi  sterspeci f i er  w i 1 1 al  most  certai  nl  y be  i gnored . Y ou 
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should  avoid  using  registerbecause the  compiler  can  usually  do  a 
betterjob  of  optimization  than  you. 


Namespaces 

Although  names  can  be  nested  insideclasses,  the  names  of  global 
functions,  global  variables,  and  cl  asses  are  still  in  a single  global 
namespace.  The  static  keyword  gives  you  some  control  over  this 
by  allowing  you  to  give  variables  and  functions  internal  linkage 
(that  is,  to  make  them  file  static).  But  in  a large  project,  lack  of 
control  over  theglobal  name  space  can  cause  problems.  To  solve 
these  problems  for  classes,  vendors  often  create  long  complicated 
names  that  are  uni  i kely  to  clash,  but  then  you're  stuck  typing  those 
names.  (A  typedef  is  often  used  to  simplify  this.)  It's  notan  elegant, 
language-supported  solution. 

You  can  subdivide  the  global  name  space  i nto  more  manageable 
pieces  usi  ng  the  namespace  feature  of  C-H-.  The  namespace 
keyword,  similar  to  cl  ass  struct  enum,  and  union,  puts  the  names 
of  its  members  in  a distinct  space.  Whilethe other  keywords  have 
additional  purposes,  the  creation  of  a new  namespace  is  the  only 
purpose  for  namespace 

Creating  a namespace 

The  creati  on  of  a namespace  i s notabi  y si  mi  I ar  to  the  creati  on  of  a 

class 

//:  C10:MyLib.cpp 
namespace  MyLib  { 

//  Declarations 

} 

int  main ( ) { } ///:- 

This  produces  a new  namespace  containing  the  enclosed 
declarations.  There  are  significant  differences  from  class  struct 
union  and  enum,  however: 
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A namespace  definition  can  appear  only  at  global  scope,  or 
nested  within  another  namespace. 


• No  termi  nati  ng  semi  col  on  i s necessary  after  the  cl  osi  ng  brace 
of  a namespace  defi  nition. 

• A namespace  definition  can  be"continued"  over  multiple 
header  fi  les  usi  ng  a syntax  that,  for  a class,  would  appear  to 
be  a redefinition: 

//:  CIO : Headerl . h 
#ifndef  HEADER1_H 
#define  HEADER1_H 
namespace  MyLib  { 
extern  int  x; 
void  f ( ) ; 

//  . . . 

} 

#endif  //  HEADER1_H  ///:- 
//:  CIO : Header2 . h 
#ifndef  HEADER2_H 
#define  HEADER2_H 
#include  "Headerl.h" 

//  Add  more  names  to  MyLib 
namespace  MyLib  { //  NOT  a redefinition! 
extern  int  y; 
void  g ( ) ; 

//  . . . 

} 

#endif  //  HEADER2_H  ///:- 
//:  CIO : Continuation . cpp 
#include  "Header2.h" 
int  main  ( ) { } / / / : ~ 

• A namespace  name  can  be  aliased  to  another  name,  so  you 
don't  havetotypean  unwieldy  name  created  by  a library 
vendor: 

// : CIO : BobsSuperDuperLibrary . cpp 
namespace  BobsSuperDuperLibrary  { 
class  Widget  { /*  ...  */  }; 


438 


Thinking  in  C+  + 


www.BruceEckel.com 


class  Poppit  { /*  ...  */  }; 

//  . . . 

} 

//  Too  much  to  type!  I'll  alias  it: 
namespace  Bob  = BobsSuperDuperLibrary; 
int  main  ( ) { } / / / : ~ 

• You  cannot  create  an  i nstance  of  a namespace  as  you  can 
with  a cl  ass. 

Unnamed  namespaces 

Each  translation  unit  contains  an  unnamed  namespace  that  you  can 
add  to  by  saying  "namespace'  without  an  identifier: 

//:  CIO : UnnamedNamespaces . cpp 
namespace  { 

class  Arm  { /*  ...  */  }; 

class  Leg  { /*  ...  */  }; 

class  Head  { /*  ...  */  }; 

class  Robot  { 

Arm  arm [ 4 ] ; 

Leg  leg [16]; 

Head  head [ 3 ] ; 

//  . . . 

} xanthan; 
int  1,  j,  k; 

} 

int  main ( ) { } ///  : ~ 

The  names  i n thi  s space  are  automat!  cal  ly  aval  I abl  e i n that 
translation  unit  without  qualification.  It  is  guaranteed  that  an 
unnamed  space  is  uniquefor  each  translation  unit.  If  you  put  local 
names  in  an  unnamed  namespace,  you  don't  need  to  givethem 
internal  linkage  by  making  them  static 

C ++  d eprecates  the  u se  of  f i I e stati  cs  i n favor  of  the  u n named 
namespace. 

Friends 

You  can  /nyect  a frienddeclarati on  into  a namespace  by  declaring  it 
within  an  enclosed  class: 
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//:  CIO : Friendin jection . cpp 
namespace  Me  { 
class  Us  { 

//.  . . 

friend  void  you  ( ) ; 


} 

int  main ( ) { } ///  : ~ 

Now  the  f u notion  you  ( )is  a member  of  the  namespace  Me. 

If  you  introduce  a friend  within  a cl  ass  in  the  global  namespace,  the 
friend  is  injected  globally. 

Using  a namespace 

You  can  refer  to  a namewithin  a namespace  in  three  ways:  by 
specifying  the  name  using  the  scope  resolution  operator,  with  a 
usingdi  recti  veto  introduce  all  names  in  the  namespace,  or  with  a 
usi  ng  deci  arati on  to  i ntroduce  names  one  at  a ti  me. 

Scope  resolution 

Any  name  i n a namespace  can  be  explicitly  specified  using  the 
scope  resol  uti  on  operator  i n the  same  way  that  you  can  refer  to  the 
names  within  a cl  ass: 


//:  CIO : ScopeResolution . cpp 
namespace  X { 
class  Y { 

static  int  i; 
public : 
void  f ( ) ; 

}; 

class  Z; 
void  f unc ( ) ; 

} 

int  X: : Y: : i = 9; 

class  X : : Z { 
int  u,  V,  w; 
public : 

Z ( int  i ) ; 
int  g ( ) ; 
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}; 

X::Z::Z(int  i)  { u = v = w = i;  } 

int  X: :Z: :g()  { return  u = v = w = 0 ; } 

void  X : : f unc  ( ) { 

X:  : Z a (1)  ; 
a . g ( ) ; 

} 

int  main  ( ) { } ///:- 

Notice  that  the  definition  X::Y::i  could  just  as  easily  be  referring  to  a 
data  member  of  a cl  ass  Y nested  in  a cl  ass  X instead  of  a namespace 

X. 

So  far,  namespaces  look  very  much  I ike  cl  asses. 

The  using  directive 

Because  it  can  rapidly  get  tedious  to  type  the  full  qualification  for 
an  identifier  in  a namespace,  the  using  keyword  allows  you  to 
import  an  entire  namespace  at  once.  When  used  in  conjunction 
with  the  namespacekeyword  this  is  cal  led  a using  directive.  The 
using  directive  makes  names  appear  as  if  they  belong  to  the  nearest 
enclosing  namespace  scope,  so  you  can  conveniently  use  the 
unqualified  names.  Consider  a simple  namespace: 

//:  CIO : Namespaceint . h 
#ifndef  NAMESPACEINT_H 
#define  NAMESPACEINT_H 
namespace  Int  { 

enum  sign  { positive,  negative  } ; 
class  Integer  { 
int  i ; 
sign  s; 
public : 

Integer (int  ii  = 0) 

: i (ii) , 

s (i  >=  0 ? positive  : negative) 

{ } 

sign  getSignO  const  { return  s;  } 
void  setSign(sign  sgn)  { s = sgn;  } 

/ / ... 

}; 
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} 

#endif  //  NAMESPACE INT_H  III'.- 

Oneuseof  theusingdirectiveisto  bring  all  of  the  names  I n Intinto 
another  namespace,  leaving  those  names  nested  within  the 
namespace: 

//:  CIO : NamespaceMath . h 
#ifndef  NAMESPACEMATH_H 
#define  NAMESPACEMATH_H 
#include  "Namespacelnt . h" 
namespace  Math  { 

using  namespace  Int; 

Integer  a,  b; 

Integer  divide ( Integer , Integer); 

//  . . . 

} 

#endif  //  NAMESPACEMATH_H  ///:- 

You  can  also  declare  all  of  the  names  in  Intinsidea  function,  but 
leavethose  names  nested  within  the  function: 

//:  CIO : Arithmetic . cpp 
#include  "Namespacelnt . h" 
void  arithmetic  0 { 

using  namespace  Int; 

Integer  x; 

X . set Sign (positive) ; 

} 

int  main  ( ) { } ///:- 

Without  the  using  directive,  all  the  names  in  the  namespace  would 
need  to  be  fully  qualified. 

One  aspect  of  the  usi ng d i recti  ve  may  seem  si  i ghti y 
counterintuitiveatfirst.Thevisibilityofthenamesi ntrod u ced  w 1 1 h 
a usi  ng  d I recti  ve  i s the  scope  I n w hi  ch  the  d i recti  ve  i s mad  e.  But 
you  can  overridethe  names  from  the  usingdirective  as  if  they've 
been  declared  globally  to  that  scope! 

//:  CIO : NamespaceOverridingl . cpp 
#include  "NamespaceMath . h" 
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int  main  ( ) { 

using  namespace  Math; 

Integer  a;  //  Hides  Math::a; 
a . set Sign (negative) ; 

//  Now  scope  resolution  is  necessary 
//  to  select  Math::a  : 

Math : : a . set Sign (positive ) ; 

} ///:- 

Suppose  you  haveasecon(d  namespace  that  contains  some  of  the 
names  in  namespace  M ath 

//:  CIO : Namespace0verriding2 . h 
#ifndef  NAMESPACEOVERRIDING2_H 
#define  NAMESPACEOVERRIDING2_H 
#include  "Namespaceint . h" 
namespace  Calculation  { 
using  namespace  Int; 

Integer  divide ( Integer , Integer); 

//  . . . 

} 

#endif  //  NAMESPACE0VERRIDING2_H  ///:- 

Si  nee  this  namespace  isai  SO  introduced  with  a using  directive,  you 
have  the  possi  bi  i ity  of  a coi  i i sion.  H owever,  the  ambi  guity  appears 
at  the  poi  nt  of  use  of  the  name,  not  at  the  usi  ng  d I recti  ve: 

//:  CIO : OverridingAmbiguity . epp 
#include  "NamespaceMath . h" 

#include  "NamespaceOverriding2 . h" 
void  s ( ) { 

using  namespace  Math; 
using  namespace  Calculation; 

//  Everything's  ok  until: 

//!  divide (1,  2);  //  Ambiguity 

} 

int  main ( ) { } ///  : ~ 

Thus,  it's  possi bieto  write usingdirectives to  introducea  number 
of  namespaces  with  confi  icti  ng  names  without  ever  produci  ng  an 
ambiguity. 
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The  using  declaration 

You  can  i nject  names  one  at  a tinne  into  the  current  scope  with  a 
us/n  g cfec/ara t/on . U n I i ke  th  e u si  n g d i recti  ve,  w h i ch  treats  n ames  as 
if  they  were  declared  globally  to  the  scope,  a usingdeclaration  Isa 
declaration  within  the  current  scope.  This  means  it  can  override 
names  from  a using  directive: 

//:  CIO : UsingDeclaration . h 
#ifndef  USINGDECLARATION_H 
#define  USINGDECLARATION_H 
namespace  U { 

inline  void  f()  {} 

inline  void  g()  {} 

} 

namespace  V { 

inline  void  f()  {} 

inline  void  g()  {} 

} 

#endif  //  USINGDECLARATION_H  ///:- 

//:  CIO : UsingDeclarationl . cpp 
#include  "UsingDeclaration . h" 
void  h()  { 

using  namespace  U;  //  Using  directive 
using  V::f;  //  Using  declaration 

f 0 ; //  Calls  V: :f 0 ; 

U::f();  //  Must  fully  qualify  to  call 

} 

int  main ( ) { } ///:- 

Theusingdeclaration  just  gives  thefully  specified  name  of  the 
identifier,  but  no  type  information.  This  means  that  if  the 
namespace  contains  a set  of  overloaded  functions  with  the  same 
name,  theusingdeclaration  declares  all  the  functions  in  the 
overloaded  set. 

You  can  put  a usingdeclaration  anywhere  a normal  declaration  can 
occur.  A usingdeclaration  works  I ike  a normal  declaration  in  all 
ways  but  one:  because  you  don't  give  an  argument  list,  it's  possible 
for  a usingdeclaration  to  cause  the  overload  of  a function  with  the 
same  argument  types  (which  isn't  allowed  with  normal 
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overloading).  This  ambiguity,  however,  doesn't  show  up  until  the 
point  of  use,  rather  than  the  point  of  declaration. 

A usingdeclaration  can  also  appear  within  a namespace,  and  it  has 
the  same  effect  as  anywhere  else  - that  name  is  declared  within  the 
space: 

//:  CIO : UsingDeclaration2 . cpp 
#include  "UsingDeclaration . h" 
namespace  Q { 
using  U : : f ; 
using  V : : g; 

//  . . . 

} 

void  m()  { 

using  namespace  Q; 
f 0 ; //  Calls  U:  :f 0 ; 
g ( ) ; //  Calls  V: : g ( ) ; 

} 

int  main  ( ) { } / / / : ~ 

A usingdeclaration  isan  alias,  and  it  allows  you  to  declare  the 
same  function  in  separate  namespaces.  If  you  end  up  re-declaring 
the  same  function  by  importing  different  namespaces,  it'sOK  - 
there  won't  beany  ambiguities  or  duplications. 

The  use  of  namespaces 

Some  of  the  rules  above  may  seem  a bit  daunting  at  fi  rst,  especial  ly 
if  you  get  the  impress!  on  that  you'll  be  using  them  all  the  time.  In 
general,  however,  you  can  getaway  with  very  simple  usage  of 
namespaces  as  long  as  you  understand  how  they  work.  The  key 
thing  to  remember  is  that  when  you  introduce  a global  using 
directive  (via  a "using  namespace  outside  of  any  scope)  you  have 
thrown  open  the  namespace  for  that  file.  This  is  usually  fine  for  an 
i mpl  ementati  on  fi  I e (a  "cpp"  f i I e)  because  the  usi  ng  d I recti  ve  i s 
only  in  effect  until  theend  of  the  compilation  of  that  file.  That  is,  it 
doesn't  affect  any  other  files,  so  you  can  adjust  the  control  of  the 
namespaces  one  implementation  file  at  a time.  For  example,  if  you 
discover  a name  cl  ash  because  of  too  many  using  directives  in  a 
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particular  implementation  file,  it  is  a simple  matter  to  change  that 
filesothat  it  uses  explicit  qualifications  or  using  declarations  to 
eliminate  the  cl  ash,  without  modifying  other  implementation  files. 

Header  files  are  a different  issue.  You  virtually  never  want  to 
introduce  a global  usingdirective  into  a header  file,  because  that 
would  mean  that  any  other  file  that  included  your  header  would 
also  have  the  namespace  thrown  open  (and  header  files  can  include 
other  header  files). 

So,  in  header  files  you  should  either  use  explicit  qualification  or 
scoped  using  directives  and  usingdeclarations.  This  isthe  practice 
that  you  will  find  in  this  book,  and  by  following  it  you  will  not 
"pollute"  the  global  namespace  and  throw  yourself  back  into  the 
pre-namespace  world  of  C-H-. 


Static  members  in  C+  + 

There  are  times  when  you  need  a single  storage  space  to  beused  by 
all  objectsof  a class.  In  C,  you  would  use  a global  variable,  but  this 
is  not  very  safe.  Global  data  can  be  modified  by  anyone,  and  its 
name  can  clash  with  other  identical  names  in  a large  project.  It 
would  be  ideal  if  the  data  could  be  stored  as  if  it  were  global,  but  be 
hidden  inside  a class,  and  clearly  associated  with  that  class. 

This  is  accomplished  with  staticdata  members  inside  a class.  There 
is  a single  piece  of  storage  for  a staticdata  member,  regardless  of 
how  many  objects  of  that  cl  ass  you  create.  A 1 1 objects  share  the 
same  static  storage  space  for  that  data  member,  so  it  isa  way  for 
them  to  "communicate"  with  each  other.  But  the  staticdata  belongs 
to  the  class;  its  name  is  scoped  inside  the  cl  ass  and  it  can  bepubiic 
private  or  protected 

Defining  storage  for  static  data  members 

Because  staticdata  has  a single  piece  of  storage  regardless  of  how 
many  objects  are  created,  that  storage  must  be  defi  ned  i n a si  ngle 
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place.  The  compi  I er  wi  1 1 not  al  I ocate  storage  for  you . The  I i nker  w i 1 1 
report  an  error  if  a staticdata  member  is  declared  but  not  defi  ned. 

The  definition  must  occur  outsidethe  class  (no  inlining  isallowed), 
and  only  one  definition  is  allowed.  Thus,  it  is  common  to  put  it  in 
the  i mplementation  fi  lefor  the  class.  The  syntax  someti  mes  gives 
people  trouble,  but  it  is  actually  quite  logical.  For  example,  if  you 
create  a stati  c data  member  i nsi  de  a cl  ass  I i ke  thi  s: 

class  A { 

static  int  i; 
public : 

//.  . . 

}; 

Then  you  must  define  storage  for  that  static  data  member  in  the 
definition  filelikethis: 

int  A : : i = 1 ; 

If  you  wereto  define  an  ordinary  global  variable,  you  would  say 

int  i = 1; 

but  here,  the  scope  resol  uti  on  operator  and  the  cl  ass  name  are  used 
to  specify  A ::i. 

Some  people  have  trouble  with  the  idea  that  A ::i  is  private  and  yet 
here's  something  that  seems  to  be  manipulating  it  right  out  in  the 
open.  Doesn't  this  break  the  protection  mechanism?  It's  a 
completely  safe  practice  for  two  reasons.  First,  the  only  place  this 
initialization  is  legal  is  in  thedefinition.  Indeed,  if  the  staticdata 
were  an  object  with  a constructor,  you  would  call  the  constructor 
instead  of  using  the  = operator.  Second,  once  the  definition  has 
been  made,  the  end-user  cannot  make  a second  definition  - the 
I i nker  w i 1 1 report  an  error.  A nd  the  cl  ass  creator  i s forced  to  create 
thedefinition  or  the  code  won't  link  during  testing.  This  ensures 
that  the  definition  happens  only  once  and  that  it's  in  the  hands  of 
the  cl  ass  creator. 
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The  entire  initialization  expression  for  a static  member  is  in  the 
scope  of  the  class.  For  example, 


//:  CIO : Statinit . cpp 
//  Scope  of  static  initializer 
#include  <iostream> 
using  namespace  std; 

int  X = 100; 

class  WithStatic  { 
static  int  x; 
static  int  y; 
public : 

void  print  0 const  { 

cout  <<  "WithStatic :: X = " <<  x <<  endl; 
cout  <<  "WithStatic :: y = " <<  y <<  endl; 

} 

}; 

int  WithStatic :: X = 1; 
int  WithStatic :: y = x + 1; 

//  WithStatic :: X NOT  ::x 

int  main  ( ) { 

WithStatic  ws; 
ws . print  ( ) ; 

} ///:- 

Here,  the  qualification  WithStaticiextencIs  the  scope  of  WithStatic 
to  the  enti  re  d ef i n i ti  on . 

static  array  initialization 

Chapter  8 introduced  the  static  const/ari  able  that  allows  you  to 
def  i ne  a constant  val  ue  i nsi  d e a cl  ass  body.  I t's  al  so  possi  bl  e to 
create  arrays  of  static  objects,  both  constand  non-const  The  syntax 
is  reasonably  consistent: 

//:  CIO : StaticArray . cpp 

//  Initializing  static  arrays  in  classes 
class  Values  { 

//  static  consts  are  initialized  in-place: 
static  const  int  scSize  = 100; 
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static  const  long  scLong  = 100; 

//  Automatic  counting  works  with  stati 

//  Arrays,  Non-integral  and  non-const 

//  must  be  initialized  externally: 

static  const  int  sclnts[]; 

static  const  long  scLongs[]; 

static  const  float  scTable[]; 

static  const  char  scLetters[]; 

static  int  size; 

static  const  float  scFloat; 

static  float  table []; 

static  char  letters []; 


int  Values: :size  = 100; 

const  float  Values :: scFloat  = 1.1; 

const  int  Values :: sclnts [ ] = { 

99,  47,  33,  11,  7 

}; 


const  long  Values :: scLongs [ ] = { 
99,  47,  33,  11,  7 

}; 


const  float  Values :: scTable [ ] = { 
1.1,  2.2,  3.3,  4.4 

}; 

const  char  Values :: scLetters [ ] = { 

'a' , 'b' , 'c' , 'd' , 'e' , 

'f,  'g',  'h',  'i',  'j' 

}; 

float  Values :: table [ 4 ] = { 

1.1,  2.2,  3.3,  4.4 

}; 

char  Values :: letters [ 10 ] = { 

'a',  'b',  'c',  'd',  'e', 

'f,  'g',  'h',  'i',  'j' 

}; 

int  mainO  { Values  v;  } ///:- 


arrays . 
tatics 
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With  static  const  of  integral  types  you  can  providethe  definitions 
inside  the  class,  but  for  everything  else  (including  arrays  of  integral 
types,  even  if  they  are  static  const  you  must  provide  a single 
external  defi  ni ti  on  for  the  member.  These  defi  niti ons  have  i nternal 
linkage,  so  they  can  be  placed  in  header  files.  The  syntax  for 
i ni  ti  al  i zi  ng  stati  c arrays  i s the  same  as  for  any  aggregate,  i ncl  ud  i ng 
automatic  counting. 

Y ou  can  al  so  create  stati  c constabjects  of  cl  ass  types  and  arrays  of 
such  objects.  However,  you  cannot  initialize  them  using  the"inline 
syntax"  allowed  for  staticcons^  of  integral  built-in  types: 


//:  CIO : StaticOb jectArrays . cpp 
//  Static  arrays  of  class  objects 
class  X { 
int  1 ; 
public : 

X ( int  11 ) : 1(11)  { } 

}; 

class  Stat  { 

//  This  doesn't  work,  although 
//  you  might  want  it  to: 

//!  static  const  X x(lOO); 

//  Both  const  and  non-const  static  class 

//  objects  must  be  initialized  externally: 

static  X x2; 

static  X xTable2[]; 

static  const  X x3; 

static  const  X xTable3[]; 

}; 


X Stat : :x2  (100)  ; 

X Stat : : xTable2  [ ] = { 

X(l),  X(2),  X(3),  X(4) 

}; 

const  X Stat :: x3  ( 100 ) ; 

const  X Stat : : xTable3  [ ] = { 
X(l),  X(2),  X(3),  X(4) 
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}; 


I int  mainO  { Stat  v;  } ///:- 

The  initialization  of  both  constand  non-conststaticarrays  of  class 
objects  must  be  performed  the  same  way,  fol  I owi  ng  the  typi  cal 
staticdefinition  syntax. 

Nested  and  local  classes 

You  can  easily  put  static  data  members  in  cl  asses  that  are  nested 
inside  other  classes.  Thedefinition  of  such  membersisan  intuitive 
and  obvious  extension  - you  simply  use  another  level  of  scope 
resolution.  However,  you  cannot  havestaticdata  members  inside 
local  classes  (a  local  class  is  a class  defined  inside  a function).  Thus, 

//:  CIO : Local . cpp 

//  Static  members  & local  classes 
#include  <iostream> 
using  namespace  std; 

//  Nested  class  CAN  have  static  data  members: 
class  Outer  { 
class  Inner  { 

static  int  i;  //  OK 


}; 


int  Outer :: inner :: i = 47; 

//  Local  class  cannot  have  static  data  members: 
void  f ( ) { 

class  Local  { 
public : 

//!  static  int  i;  //  Error 

//  (How  would  you  define  i?) 

} x; 

} 

int  mainO  { Outer  x;  f();  } ///:- 
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You  can  seethe  inrimediateproblenn  with  a static mennber  in  a iocai 
dass:  How  do  you  d escri  be  the  data  mennber  at  fiie  scope  in  order 
to  define  it?  in  practice,  iocai  dasses  are  used  very  rareiy. 

Static  member  functions 

You  can  ai  so  create  static  member  functions  that,  i ike  static  data 
members,  work  for  the  dass  as  a whoie  rather  than  for  a parti cuiar 
object  of  a dass.  instead  of  making  agiobai  function  thatiivesin 
and  "poiiutes"  thegiobai  or  iocai  namespace,  you  bring  the 
function  inside  the  dass.  When  you  create  a static  member 
function,  you  are  expressing  an  association  with  a parti  cuiar  ciass. 

You  can  caii  a static  member  function  in  the  ordinary  way,  with  the 
dot  or  the  arrow,  in  association  with  an  object.  However,  it's  more 
typicai  to  caii  a static  member  function  by  itseif,  without  any 
specific  object,  using  thescope-resoiution  operator,  i ike  this: 

// : CIO : SimpleStaticMemberFunction . cpp 
class  X { 
public : 

static  void  f ( ) { } ; 

}; 


int  main  ( ) { 

X:  :f  0 ; 

} ///:- 

When  you  see  static  member  functions  i n a ciass,  remember  that  the 
designer  intended  that  function  to  beconceptuaiiy  associated  with 
the  ciass  as  a whoie. 

A static  member  function  cannot  accessordinary  data  members, 
oniy  staticdata  members,  it  can  caii  oniy  other  staticmember 
functions.  Normaiiy,  theaddressofthecurrent  object  (this)  is 
quietiy  passed  in  when  any  member  function  iscaiied,  but  a static 
member  has  no  this  which  isthe  reason  it  cannot  access  ordinary 
members.  Thus,  you  get  the  tiny  increase  in  speed  afforded  by  a 
giobai  function  because  a static  member  function  doesn't  have  the 
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©(tra  overhead  of  passing  this  Atthe  same  time  you  get  the 
benefits  of  havi  ng  the  fu  ncti  on  i nsi  de  the  cl  ass. 


For  data  members,  static  indicates  that  only  one  piece  of  storagefor 
member  data  exists  for  all  objects  of  a class.  This  parallels  the  use  of 
staticto  define  objects  /ns/de a function  to  mean  that  only  one  copy 
of  a local  variable  is  used  for  all  cal  Is  of  that  function. 

Here's  an  example  showing  staticdata  members  and  staticmember 
functions  used  together: 

// : CIO : StaticMemberFunctions . cpp 
class  X { 
int  i ; 

static  int  j; 
public : 

X ( int  ii  = 0)  : i(ii)  { 

//  Non-static  member  function  can  access 
//  static  member  function  or  data: 

j = i; 

} 

int  val()  const  { return  i;  } 
static  int  incr()  { 

//!  i++;  //  Error:  static  member  function 

//  cannot  access  non-static  member  data 
return  ++j; 

} 

static  int  f ( ) { 

//!  val();  //  Error:  static  member  function 
//  cannot  access  non-static  member  function 
return  incr();  //  OK  — calls  static 


}; 


int  X : : j = 0 ; 

int  main  ( ) { 

X X ; 

X*  xp  = &x; 

X . f ( ) ; 

xp->f ( ) ; 

X::f();  //  Only  works  with  static  members 
} ///:- 
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Because  they  have  no  this  pointer,  static  member  functions  can 
neither  access  non-staticdata  members  nor  call  non-static  member 
functions. 

Notice  in  main(  )that  a staticmember  can  be  selected  using  the 
usual  dot  or  arrow  syntax,  associating  that  function  with  an  object, 
but  also  with  no  object  (because  a staticmember  is  associated  with 
a class,  not  a particular  object),  using  the  cl  ass  name  and  scope 
resolution  operator. 

Here'san  interesting  feature:  Because  of  the  way  initialization 
happens  for  staticmember  objects,  you  can  put  a staticdata 
member  of  the  same  cl  ass /ns/de  that  cl  ass.  Here'san  example  that 
allows  only  a single  object  of  type  Egg  to  exist  by  making  the 
constructor  private.  You  can  access  that  object,  but  you  can't  create 
any  new  Egg  objects: 

//:  CIO : Singleton . cpp 

//  Static  member  of  same  type,  ensures  that 
//  only  one  object  of  this  type  exists. 

//  Also  referred  to  as  the  "singleton"  pattern. 

#include  <iostream> 
using  namespace  std; 

class  Egg  { 
static  Egg  e; 
int  i ; 

Egg(int  ii)  : i(ii)  {} 

Egg (const  Egg&);  //  Prevent  copy-construction 
public : 

static  Egg*  instance ()  { return  &e;  } 

int  val()  const  { return  i;  } 

}; 


Egg  Egg : : e ( 47 ) ; 
int  main  ( ) { 

//!  Egg  x(l);  //  Error  — can't  create  an  Egg 

//  You  can  access  the  single  instance: 
cout  <<  Egg :: instance  0 ->val ( ) <<  endl; 

} ///:- 
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The  initialization  for  E happens  after  the  class  declaration  is 
complete,  so  the  compiler  has  all  the  information  it  needs  to 
al  I ocate  storage  and  make  the  constructor  cal  I . 

To  completely  prevent  the  creation  of  any  other  objects,  something 
else  has  been  added:  asecond  private  constructor  called  the  copy- 
constructor.  At  this  point  in  the  book,  you  cannot  know  why  this  is 
necessary  si  nee  the  copy  constructor  will  not  be  introduced  until 
the  next  chapter.  However,  as  a sneak  preview,  if  you  were  to 
remove  the  copy-constructor  defined  in  the  example  above,  you'd 
be  abl e to  create  an  Egg  object  I i ke  this: 

Egg  e = *Egg :: instance  () ; 

Egg  e2 ( *Egg :: instance  0) ; 

Both  of  these  use  the  copy-constructor,  so  to  seal  off  that  possi  bi  I ity 
the  copy-constructor  is  declared  as  private  (no  definition  is 
necessary  because  it  never  gets  cal  led).  A large  portion  of  the  next 
chapter  is  a discussion  of  the  copy-constructor  so  it  should  become 
clear  to  you  then. 


static  initialization  dependency 

Within  a specific  translation  unit,  the  order  of  initialization  of  static 
objects  is  guaranteed  to  be  the  order  in  which  the  object  definitions 
appear  in  that  translation  unit.  The  order  of  destruction  is 
guaranteed  to  be  the  reverse  of  the  order  of  initialization. 

However,  there  is  no  guarantee  concerning  the  order  of 
initialization  of  static  objects  across  translation  units,  and  the 
language  provides  no  way  to  specify  this  order.  This  can  cause 
si  g n i f i cant  probi  ems.  A s an  examp  I e of  an  i nstant  d i saster  ( w h i ch 
will  halt  primitive  operating  systems  and  kill  the  process  on 
sophisticated  ones),  if  one  file  contains 

//  First  file 
#include  <fstream> 
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std:  : of stream  out ( "out . txt " ) ; 


and  another  file  uses  the  out  object  in  oneof  its  initializers 

//  Second  file 
#include  <fstream> 
extern  std: : of stream  out; 
class  Oof  { 
public : 

0of()  { std::out  <<  "ouch";  } 

} oof; 

the  program  may  work,  and  it  may  not.  If  the  programming 
en vi  ron ment  bu i I ds  the  program  so  that  the  f i rst  f i I e i s i n i ti  al  i zed 
before  the  second  file,  then  therewill  be  no  problem.  However,  if 
the  second  f i I e i s i ni  ti  al  i zed  before  the  f i rst,  the  constructor  for  0 of 
relies  upon  the  existence  of  out  which  hasn't  been  constructed  yet 
and  this  causes  chaos. 

This  problem  only  occurs  with  static  object  initializers  that  depend 
on  each  other.  The  statics  in  a translation  unit  are  initialized  before 
the  first  invocation  of  a function  in  that  unit  - but  it  could  be  after 
main( ) You  can't  be  sure  about  the  order  of  initialization  of  static 
objects  if  they're  in  different  files. 

A subtler  example  can  befound  intheARM.^  In  onefileyou  have 
at  the  global  scope: 

extern  Int  y; 

Int  X = y + 1; 

and  in  a second  file  you  have  at  the  global  scope: 

extern  Int  x; 

Int  y = X + 1; 


^BjarneStroustrup  and  Margaret  Ellis,  TheAnnotated  C++  ReferenceM  anual,  Addison- 
Wesley,  1990,  pp.  20-21. 
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For  all  static  objects,  the  linking-loading  mechanism  guarantees  a 
static  initialization  to  zero  before thedynamic  initialization 
specified  by  the  programmer  takes  place.  In  the  previous  example, 
zeroing  of  the  storage  occupied  by  the f stream  outobject  has  no 
special  meaning,  so  it  istruly  undefined  until  the  constructor  is 
called.  However,  with  built-in  types,  initialization  to  zero  does  have 
meaning,  and  if  the  files  are  initialized  in  the  order  they  are  shown 
above,y  begins  as  statically  initialized  to  zero,  soxbecomes  one, 
and  y isdynamically  initialized  to  two.  However,  if  the  files  are 
initialized  in  the  opposite  order,  x is  statically  initialized  to  zero,  y 
isdynamically  initialized  to  one,  and  xthen  becomes  two. 

Programmers  must  be  aware  of  this  because  they  can  create  a 
program  with  static  initialization  dependencies  and  get  it  working 
on  one  platform,  but  move  it  to  another  compiling  environment 
where  it  suddenly,  mysteriously,  doesn't  work. 

What  to  do 

There  are  three  approaches  to  dealing  with  this  problem: 

1.  Don't  do  it.  Avoiding  static  initialization  dependencies  isthe 
best  solution. 

2.  If  you  must  do  it,  put  the  critical  static  object  definitions  in  a 
singlefile,  so  you  can  portably  control  their  initialization  by 
putti  ng  them  i n the  correct  order. 

3.  If  you're  convinced  it's  unavoidableto  scatter  static  objects 
across  translation  units  - as  in  the  case  of  a I i brary,  where 
you  can't  control  the  programmer  who  uses  it  - there  are  two 
programmati  c techni  ques  to  sol  ve  the  probi  em. 

Technique  one 

This  techni que  was  pi oneered  by  J erry  Schwarz  while  creati  ng  the 
iostream  library  (because  the  definitions  for  cin,  cout  and  cerrare 
staticand  livein  aseparatefile).  It's  actually  inferior  to  the  second 
technique  but  it's  been  around  along  time  and  so  you  may  come 
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across  code  that  uses  it;  thus  it's  i mportant  that  you  understand 
how  it  works. 


Thistechnique  requires  an  additional  class  in  your  library  header 
f i I e.  Thi  s cl  ass  i s responsi  bl  e for  the  dy  nami  c i n i ti  al  i zati  on  of  you  r 
li  brary's  static  objects.  H ere  is  a si  mple  example: 

//:  CIO : Initializer . h 

//  Static  initialization  technique 

#ifndef  INITIALIZERS 

#define  INITIALIZERS 

#include  <iostream> 

extern  int  x;  //  Declarations,  not  definitions 
extern  int  y; 

class  Initializer  { 

static  int  initCount; 
public : 

Initializer ( ) { 

std::cout  <<  "Initializer  () " <<  std::endl; 

//  Initialize  first  time  only 
if  ( initCount+t  ==  0)  { 

std::cout  <<  "performing  initialization" 

<<  std : : endl ; 

X = 100; 

y = 200; 


~Initializer ( ) { 

std::cout  <<  "~Initializer ( ) " <<  std::endl; 
//  Clean  up  last  time  only 
if ( — initCount  ==  0)  { 

std::cout  <<  "performing  cleanup" 

<<  std : : endl ; 

//  Any  necessary  cleanup  here 


}; 


//  The  following  creates  one  object  in  each 
//  file  where  Initializer . h is  included,  but  that 
//  object  is  only  visible  within  that  file: 
static  Initializer  init; 
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#endif  //  INITIALIZERS  ///:- 

The  declarations  for  x and  y announce  only  that  these  objects  exist, 
but  they  don't  al  locate  storage  for  the  objects.  H owever,  the 
definition  for  the  Initializer  initellocates  storage  for  that  object  in 
every  file  where  the  header  is  included.  But  becausethenameis 
static  (control  ling  visibility  this  time,  nottheway  storageis 
al  I ocated ; storage  i s at  fi  I e scope  by  d efau  1 1) , i t i s v i si  bl  e on  I y w i th  i n 
that  translation  unit,  so  the  linker  will  not  complain  about  multiple 
definition  errors. 

H ere  i s the f i I e contai ni ng  the  defi ni ti ons  for  x,  y,  and  i nitC ount 

//:  CIO : InitializerDef s . cpp  {0} 

//  Definitions  for  Initializer . h 
#include  "Initializer . h" 

//  Static  initialization  will  force 
//  all  these  values  to  zero: 
int  X ; 
int  y; 

int  Initializer :: initCount ; 

///:- 

(Of  course,  afilestatic  instance  of  initisal  so  placed  inthisfile 
when  the  header  is  included.)  Supposethat  two  other  files  are 
created  by  the  I i brary  user: 

//:  CIO : Initializer . cpp  {0} 

//  Static  initialization 
#include  "Initializer . h" 

///:- 

and 

//:  CIO : InitializerC . cpp 
//{L}  InitializerDef s Initializer 
//  Static  initialization 
#include  "Initializer . h" 
using  namespace  std; 

int  main  ( ) { 

cout  <<  "inside  main()"  <<  endl; 
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cout  <<  "leaving  main()"  <<  endl; 

} III-.- 

Now  it  doesn't  matter  which  translation  unit  is  initialized  first.  The 
f i rst  ti  me  a transi  ati  on  u n i t contai  n i ng  I n i ti al  i zer.hi  s i n i ti  al  i zed , 
initCountwill  bezero  so  the  initialization  will  be  performed.  (This 
depends  heavi  ly  on  the  fact  that  the  static  storage  area  is  set  to  zero 
before  any  dynamic  initialization  takes  place.)  For  all  the  rest  of  the 
translation  units,  initCountwill  be  nonzero  and  the  initialization 
will  be  skipped.  Cleanup  happens  in  the  reverse  order,  and 
~lnitiaiizer(  ^sures  that  it  will  happen  only  once. 

This  example  used  built-in  types  as  the  global  static  objects.  The 
technique  also  works  with  classes,  but  those  objects  must  then  be 
dynamically  initialized  by  thelnitiaiizerclass.  Oneway  to  do  this 
isto  create  the  classes  without  constructors  and  destructors,  but 
instead  with  initialization  and  cleanup  member  functions  using 
different  names.  A more  common  approach,  however,  isto  have 
pointers  to  objects  and  to  create  them  using  new  inside 
lnitializer( ) 

Technique  two 

Long  after  technique  one  was  in  use,  someone  (I  don't  know  who) 
cameup  with  thetechniqueexplained  in  thissection,  which  is 
much  simpler  and  cleaner  than  technique  one.  The  fact  that  it  took 
so  I ong  to  d i scover  i s a tri  bute  to  the  compi  exi ty  of  C -H-. 

This  technique  relies  on  the  fact  that  static  objects  inside  functions 
are  initialized  the  first  time  (only)  that  the  function  iscalled.  Keep 
i n mi  nd  that  the  probi  em  we're  real  ly  try!  ng  to  sol  ve  here  i s not 
\Nh&\  thestatic  objects  are  initialized  (that  can  decontrolled 
separately)  but  rather  making  surethat  the  initialization  happensin 
the  proper  order. 

This  technique  is  very  neat  and  clever.  For  any  initialization 
dependency,  you  place  a static  object  inside  a function  that  returns 
a reference  to  that  object.  This  way,  the  only  way  you  can  access  the 
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static  object  is  by  calling  the  function,  and  if  that  object  needs  to 
accessother  static  objects  on  which  it  is  dependent  it  must  cal  I thdr 
functions.  And  the  first  time  a function  is  cal  led,  it  forces  the 
initialization  to  take  pi  ace.  The  order  of  static  initialization  is 
guaranteed  to  be  correct  because  of  the  design  of  the  code,  not 
because  of  an  arbitrary  order  established  by  the  linker. 

To  set  up  an  example,  here  are  two  cl  asses  that  depend  on  each 
other.  The fi  rst  one  contai  ns  a bool  that  is  i nitial  ized  only  by  the 
constructor,  so  you  can  tell  if  the  constructor  has  been  called  for  a 
static  i nstance  of  the  class  (the  static  storage  area  is  i nitial  ized  to 
zero  at  program  startup,  which  produces  a falsevalue for  the  bool 
if  the  constructor  has  not  been  called): 

//:  CIO : Dependency! . h 
#ifndef  DEPENDENCY1_H 
#define  DEPENDENCY1_H 
#include  <iostream> 

class  Dependency!  { 
boo!  init; 
public : 

Dependency!  ( ) : init (true)  { 

std::cout  <<  "Dependency!  construction" 

<<  std : : end! ; 


void  print  0 const  { 

std::cout  <<  "Dependency!  init:  " 
<<  init  <<  std::endl; 


}; 

#endif  //  DEPENDENCY1_H  ///:- 

The  constructor  also  announces  when  it  is  being  called,  and  you 
can  prlnt(  )the  state  of  the  object  to  fi  nd  out  if  it  has  been 
initialized. 

The  second  class  is  initialized  from  an  object  of  the  first  class,  which 
iswhatwill  cause  the  dependency: 

//:  CIO : Dependency2 . h 
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#ifndef  DEPENDENCY2_H 
#define  DEPENDENCY2_H 
#include  "Dependency! . h" 

class  Dependency2  { 

Dependency!  d!; 
public : 

Dependency2 (const  Dependencyl&  depl):  d!(dep!){ 
std::cout  <<  "Dependency2  construction 
print  ( ) ; 

} 

void  print  0 const  { dl.printO;  } 

}; 

#endif  //  DEPENDENCY2_H  ///:- 

The  constructor  announces  itself  and  pri  nts  the  state  of  the  d 1 
object  so  you  can  see  if  it  has  been  initialized  by  the  time  the 
constructor  is  cal  led. 

T 0 demonstrate  what  can  go  wrong,  the  fol  lowi  ng  fi  I e fi  rst  puts  the 
static  object  definitions  in  the  wrong  order,  as  they  would  occur  if 
thelinker  happened  to  initializetheDependencyZobject  before  the 
Dependency lobject.  Then  the  order  is  reversed  to  show  how  it 
works  correctly  if  the  order  happens  to  be  "right."  Lastly,  technique 
two  is  demonstrated. 

To  provide  more  readable  output,  thefunction  separator(  )is 
created.  The  trick  is  that  you  can't  call  a function  globally  unless 
that  function  isbeing  used  to  perform  the  initialization  of  a 
variable,  so  separator(  )returns  a dummy  value  that  is  used  to 
initializea  couple  of  global  variables. 

//:  CIO : Technique2 . cpp 
#include  "Dependency2 . h" 
using  namespace  std; 


//  Returns  a value  so  it  can  be  called  as 
//  a global  initializer: 
int  separator  0 { 

cout  <<  " " <<  endl; 

return  1; 
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} 

//  Simulate  the  dependency  problem: 
extern  Dependency!  depl; 

Dependency2  dep2(depl); 

Dependency!  depl; 
int  xl  = separator  0; 

//  But  if  it  happens  in  this  order  it  works  OK: 

Dependency!  deplb; 

Dependency2  dep2b (deplb) ; 
int  x2  = separator  0; 

//  Wrapping  static  objects  in  functions  succeeds 
Dependencyl&  dl ( ) { 

static  Dependency!  depl; 
return  depl; 

} 

Dependency2&  d2 ( ) { 

static  Dependency2  dep2(dl()); 
return  dep2; 

} 

int  main  ( ) { 

Dependency2&  dep2  = d2 ( ) ; 

} ///:- 

Thefunctionsdl(  )and  d2(  )wrap  static  instances  of  Dependency! 
and  Dependency2objects.  Now,theonly  way  you  can  get  to  the 
stati  c objects  i s by  cal  I i ng  the  fu ncti  ons  and  that  forces  stati  c 
initialization  on  the  first  function  call.  This  means  that  initialization 
is  guaranteed  to  be  correct,  which  you'll  see  when  you  run  the 
program  and  look  at  the  output. 

Here'show  you  would  actually  organize  the  code  to  use  the 
technique.  Ordinarily,  the  static  objects  would  be  defined  in 
separated  les  (because  you 're  forced  to  for  some  reason;  remember 
that  defi  ni  ng  the  stati c objects  i n separate  f i I es  i s what  causes  the 
problem),  so  instead  you  define  the  wrapping  functions  in  separate 
files.  But  they'll  need  to  be  declared  in  header  files: 
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// : CIO : DependencylStatFun . h 
#ifndef  DEPENDENCY1STATFUN_H 
#define  DEPENDENCY1STATFUN_H 
#include  "Dependency! . h" 
extern  Dependencyl&  dl(); 

#endif  //  DEPENDENCY1STATFUN_H  ///:- 

Actually,  the  "©(tern"  is  redundant  for  the  function  declaration. 

H ere's  the  second  header  file: 

// : CIO : DependencyCStatFun . h 
#ifndef  DEPENDENCY2STATFUN_H 
#define  DEPENDENCY2STATFUN_H 
#include  "Dependency2 . h" 
extern  Dependency2&  d2 ( ) ; 

#endif  //  DEPENDENCY2STATFUN_H  ///:- 

Now,  in  theimplennentation  files  where  you  would  previously 
have  placed  the  static  object  definitions,  you  instead  place  the 
wrapping  function  definitions: 

//:  CIO : DependencylStatFun . cpp  {0} 

#include  "DependencylStatFun . h" 

Dependencyl&  dl()  { 

static  Dependency!  depl; 
return  depl; 

} ///:- 

Presumably,  other  code  might  also  be  placed  in  these  files.  Here's 
the  other  file: 

//:  CIO : Dependency2StatFun . cpp  {0} 

#include  "DependencylStatFun . h" 

#include  "Dependency2StatFun . h" 

Dependency2&  d2 ( ) { 

static  Dependency2  dep2(dl()); 
return  dep2; 

} ///:- 

So  now  there  are  two  files  that  could  delinked  in  any  order  and  if 
they  contained  ordinary  static  objects  could  produce  any  order  of 
initialization.  But  si  nee  they  contain  the  wrapping  functions,  there's 
no  threat  of  incorrect  initialization: 
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//:  CIO : Technique2b . cpp 

//{L}  DependencylStatFun  Dependency2StatFun 
#include  "Dependency2StatFun . h" 
int  mainO  { d2  ( ) ; } ///:- 

When  you  run  this  program  you'll  seethatthe  initialization  of  the 
Dependencylstatic  object  always  happens  before  the  initialization 
of  the  DependencyZstatic  object.  You  can  alsoseethatthisisa 
much  simpler  approach  than  technique  one. 

You  might  be  tempted  to  writedl(  )and  d2(  )as  inline  functions 
i nsi de thei r respect! ve  header  f i I es,  but  thi s i s someth! ng  you  must 
definitely  not  do.  An  inline  function  can  beduplicated  in  every  file 
in  which  it  appears-  and  this  duplication  /nc/tydesthestaticobject 
definition.  Because  inlinefunctions  automatically  default  to 
internal  linkage,  this  would  result  in  having  multi  pie  static  objects 
across  the  various  translation  units,  which  would  certainly  cause 
problems.  So  you  must  ensurethat  there  is  only  one  definition  of 
each  wrapping  function,  and  this  means  not  making  the  wrapping 
functions  inline. 


Alternate  linkage  specifications 

What  happens  if  you're  writing  a program  in  C++ and  you  want  to 
useaC  library?  If  you  maketheC  function  declaration, 

I float  f (int  a,  char  b) ; 

theC++ compiler  will  decorate  this  name  to  something  like 
_f_int_charto  support  function  overloading  (and  type-safe 
linkage).  However,  theC  compiler  that  compiled  yourC  library  has 
most  definitely  not  decorated  the  name,  so  its  internal  name  will  be 
_f . Thus,  the  I i nker  wi  1 1 not  be  abl  e to  resol  ve  you  r C -H-  cal  I s to  f ( ). 

The  escape  mechanism  provided  in  C-H- is  the  a/ternateZ/nkage 
specification,  which  was  produced  in  the  language  by  overloading 
the  extern  keyword . The  extern  I s fol  I owed  by  a stri  ng  that 
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specifies  the  linkage  you  want  for  the  declaration,  followed  by  the 
declaration: 


extern  "C"  float  f (int  a,  char  b) ; 

This  tel  Is  the  compiler  to  giveC  linkage  to  f( ) so  that  the  compiler 
doesn't  decorate  the  name.  The  only  two  types  of  li  nkage 
specif!  cations  supported  by  the  standard  are"C"and  "C++, "but 
compi  I er  vendors  have  the  opti  on  of  su  pporti  ng  other  I anguages  i n 
the  same  way. 

If  you  have  a group  of  declarations  with  alternate  linkage,  put  them 
inside  braces,  I ike  this: 

extern  "C"  { 

float  f (int  a,  char  b) ; 
double  d(int  a,  char  b) ; 

} 

Or,  fora  header  file, 

extern  "C"  { 

#include  "Myheader.h" 

} 

M ost  C ++  compi  I er  vendors  hand  I e the  alternate  I i nkage 
specifications  insidetheir  header  files  that  work  with  both  C and 
C++,  so  you  don't  have  to  worry  about  it. 


Summary 

The  Static  keyword  can  be  confusing  because  in  some  situations  it 
controls  the  location  of  storage,  and  in  others  it  controls  visibility 
and  I i nkage  of  a name. 

With  the  introduction  of  C++ namespaces,  you  have  an  improved 
and  more  flexible  alternative  to  control  the  proliferation  of  names 
in  large  projects. 
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The  use  of  static  inside  classes  is  one  more  way  to  control  names  in 
a program.  The  names  do  not  clash  with  global  names,  and  the 
visibility  and  access  is  kept  within  the  program,  giving  you  greater 
control  in  the  maintenance  of  your  code. 


Exercises 

Solutions  to  selected  exercises  can  be  found  in  the  electronic  document  TheThinking  in  C++ Annotated 
Solution  Guide,  aval  I able  for  a small  feefromwww.BruceEckel.com. 

1.  Create  a function  with  a static  variable  that  is  a pointer 
(with  a default  argument  of  zero).  When  the  caller 
provides  a valuefor  this  argument  it  is  used  to  point  at 
the  beginning  of  an  array  of  int  Ifyou  call  thefunction 
with  a zero  argument  (using  the  default  argument),  the 
function  returnsthe  next  value  in  the  array,  until  it  sees  a 
"-1"  val  ue  i n the  array  (to  act  as  an  end-of-array 
indicator).  Exercise  this  function  in  main( ) 

2.  Create  a function  that  returns  the  next  value  in  a 
Fibonacci  sequence  every  time  you  call  it.  Add  an 
argument  that  is  a bool  with  a default  value  of  false  such 
that  when  you  givethe argument  with  trueit  "resets"  the 
function  to  the  beginning  of  the  Fibonacci  sequence. 
Exercise  this  function  in  maln( ) 

3.  Create  a cl  ass  that  holds  an  array  of  lots.  Set  the  size  of 
the  array  using  static  const  intnsidethe  class.  Add  a 
const!  nt  variable,  and  initialize  it  in  the  constructor 
initializer  list;  make  the  constructor  inline  Add  astatic 
int  member  variable  and  initialize  it  to  a specific  value. 
Add  a staticmember  function  that  prints  the staticdata 
member.  Add  an  inlinemember  function  called  print( ) 
to  pri  nt  out  al  I the  val  ues  i n the  array  and  to  cal  I the 
staticmember  function.  Exercise  this  cl  ass  in  main( ) 

4.  Create  a cl  ass  cal  led  M onitorthat  keeps  track  of  the 
number  of  times  that  its  incident!  )member  function  has 
been  called.  Add  a print!  )member  function  that  displays 
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thenumber  of  incidents.  Now  create  a giobai  function 
(not  a member  function)  containing  a staticMonitor 
object.  Each  time  you  caii  thefunction  itshouid  caii 
incident(  )then  print(  )todispiay  the  incident  count. 
Exercise  the  function  in  main( ) 

5.  Modify  the  Monitord  ass  from  Exercise  4 so  that  you  can 
decrement!  )the  incident  count.  MakeadassMonitor2 
that  takes  as  a constructor  argument  a poi  nter  to  a 
Monitor!  and  which  stores  that  poi  nter  and  caiis 
incident!  )and  print! ) in  the  destructor  for  Monitor! 
caii  decrement!  )and  print! ) Now  makeastaticobject 
of  Monitor2inside  a function,  inside  main! ) experiment 
with  caiiing  thefunction  and  not  caiiing  the  function  to 
see  what  happens  with  the  destructor  of  M onitor2 

6.  Makea  giobai  object  of  Monitor2and  see  what  happens. 

7.  C reate  a ci ass  with  a destructor  that  prints  a message  and 
then  caiis  exit! ) Create  a giobai  object  ofthisci  ass  and 
see  what  happens. 

8.  in  StaticD  estructors.cppexperi  ment  with  the  order  of 
constructor  and  destructor  caiisby  caiiing  f!  )and  g! ) 
inside  main!  )in  different  orders.  Does  your  compiier  get 
it  right? 

9.  in  StaticD estructorsxpptest the defauit error  handiing 
of  your  impiementation  by  turning  the  originai  definition 
of  out  into  an  extern  deciarati  on  and  putting  theactuai 
definition  after  the  definition  ofa(whoseObj  constructor 
sends  information  to  out).  Make  sure  there's  nothing  eise 
important  running  on  your  machine  when  you  run  the 
program  or  that  your  machine  wiii  hand iefau its 
robustiy. 

10.  Provethatfiiestatic  variabies  in  header  fiies  don't  dash 
with  each  other  when  inciuded  in  more  than  onecppfiie. 

11.  Createa  simpieciass  containing  an  int  a constructor  that 
initiaiizestheintfrom  its  argument,  a member  function 
to  settheintfrom  its  argument,  and  a print!  )function 
that  prints  the  int  Put  you  rd  ass  in  a header  fiie,  and 
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includetheheader  file  in  two  cpp files.  In  onecppfile 
make  an  instance  of  your  cl  ass,  and  in  the  other  declare 
that  identifier  extern  and  test  it  inside  main( ) 

Remember,  you'l  I have  to  I i nk  the  two  object  f i I es  or  el  se 
the  I inker  won't  find  the  object. 

12.  Maketheinstanceof  the  object  in  Exercise  11  staticand 
verify  that  it  cannot  be  found  by  the  linker  because  of 
this. 

13.  Declare  a function  in  a header  file.  Define  the  function  in 
onecppfileand  call  it  insidemain(  )in  a second  cpp  file. 
Compile  and  verify  that  it  works.  Now  change  the 
function  definition  so  that  it  is  staticand  verify  that  the 
linker  cannot  find  it. 

14.  Modify  Volatilexppfrom  Chapter  8to  make 
comm::isr(  Jsomething  that  could  actually  work  as  an 
interrupt  service  routine.  H int:  an  interrupt  service 
routi  ne  d oesn 't  take  any  argu  ments. 

15.  Write  and  compilea  simple  program  that  uses  the  auto 
and  regi  Starkey  words. 

16.  Create  a header  file  containing  a namespace  Inside  the 
namespacecreate several  function  declarations.  Now 
create  a second  header  file  that  includes  the  first  one  and 
continues  the  namespace  adding  several  more  function 
declarations.  Now  create  a cpp  file  that  includes  the 
second  header  file.  A lias  your  namespace  to  another 
(shorter)  name.  Inside  a function  definition,  call  one  of 
your  functions  using  scope  resolution.  Inside  a separate 
function  definition,  write  a using  directive  to  introduce 
your  namespace  i nto  that  function  scope,  and  show  that 
you  don't  need  scope  resolution  to  call  the  functions  from 
your  namespace. 

17.  Create  a header  file  with  an  unnamed  namespace. 

I ncl  ude  the  header  i n two  separate  cpp  f i I es  and  show 
that  an  unnamed  space  is  uniquefor  each  translation 
unit. 
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18.  Using  the  header  file  from  Exercise  17,  show  that  the 
names  in  an  unnamed  namespace  are  automatically 
availablein  atranslation  unit  without  qualification. 

19.  Modify  Friendlnjection.cp|to  add  a definition  for  the 
friend  function  and  to  call  the  function  inside  main( ) 

20.  I n A rithmeti c.cpp  demonstrate  that  the  usi  ng  d i recti  ve 
does  not  extend  outside  the  function  in  which  the 
directive  was  made. 

21.  Repair  the  problem  in  OverridingAmbiguity.cppfirst 
with  scope  resolution,  then  instead  with  a using 
declaration  that  forces  the  compi  ler  to  choose  one  of  the 
identical  function  names. 

22.  In  two  header  files,  create  two  namespaces,  each 
containing  aclass(with  all  inline  definitions)  with  a 
name  identical  to  that  i n the  other  namespace.  Create  a 
cpp  file  that  includes  both  header  files.  Create  a function, 
and  inside  the  function  use  the  using  directive  to 

i ntroduce  both  namespaces.  T ry  creati  ng  an  object  of  the 
class  and  see  what  happens.  Make  the  using  directives 
global  (outside  of  thefunction)  to  see  if  it  makes  any 
difference.  Repair  the  problem  using  scope  resolution, 
and  create  objects  of  both  classes. 

23.  Repair  the  problem  in  Exercise  22  with  a using 
declaration  that  forces  the  compi  ler  to  choose  one  of  the 
identical  class  names. 

24.  Extract  the  namespace  declarations  i n 
BobsSuperDuperLibrary.cppind 
UnnamedNamespaces.cp(»nd  put  them  in  separate 
header  fi  les,  giving  the  unnamed  namespace  a name  in 
the  process.  I n a thi  rd  header  fi  le  create  a new  namespace 
that  combi  nes  the  el  ements  of  the  other  two  namespaces 
with  usingdeclarations.  In  main( ) introduce  your  new 
namespacewith  a using  directive  and  access  all  the 
elements  of  your  namespace. 

25.  Create  a header  file  that  includes  <string>and 
<iostream>but  does  not  use  any  using  directives  or 
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usingdeclarations.  Add  "include  guards"  as  you've  seen 
in  the  header  files  in  this  book.  Create  a class  with  all 
inlinefunctionsthat  contains  a stringmember,  with  a 
constructor  that  initializes  that  stringfrom  its  argument 
and  aprint(  )fu notion  that  displays  the  string  Create  a 
cppfileand  exercise  your  cl  ass  in  main( ) 

26.  Createa  classcontaining  astaticdoubleand  long  Write 
a static  member  function  that  pri  nts  out  the  values. 

27.  C reate  a cl  ass  contai  ni  ng  an  i nt;  a constructor  that 
initializes theintfrom  its  argument,  and  a print( ) 
function  to  display  theint  Now  create  a second  class 
that  contains  a staticobject  of  thefirst  one.  Add  a static 
member  fu  ncti  on  that  cal  I s the  stati  cobject's  pri  nt( ) 
function.  Exercise  your  class  in  main( ) 

28.  Createa  classcontaining  both  aconstand  a non-const 
staticarray  of  int  Write staticmethods  to  print  out  the 
arrays.  Exercise  your  class  in  main( ) 

29.  Createa  classcontaining  a string  with  a constructor  that 
initializes  thestringfrom  its  argument,  and  aprint( ) 
function  to  display  the  string  Create  another  cl  ass  that 
contains  both  constand  non-conststaticarrays  of  objects 
of  thefirst  class,  and  staticmethods  to  print  out  these 
arrays.  Exercise  this  second  cl  ass  in  main( ) 

30.  Create  a structthat  contai  ns  an  inland  a default 
constructor  that  initial  izes  the  intto  zero.  Make  this 
structlocal  toafunction.  Inside  that  function,  create  an 
array  of  objects  of  your  structand  demonstrate  that  each 
intin  the  array  has  automatically  been  initialized  to  zero. 

31.  C reate  a cl  ass  that  represents  a pri  nter  connection,  and 
that  only  al  lows  you  to  have  one  pri  nter. 

32.  In  aheaderfile,  create  a cl  ass  Mirrorthat  contai  ns  two 
data  members:  a pointer  to  a M irrorobject  and  a booi. 
Give  it  two  constructors:  the  default  constructor 

i nitial  izes  the  booi  to  trueand  the  M irrorpoi  nter  to  zero. 
The  second  constructor  takes  as  an  argument  a pointer  to 
a M irrorobject,  which  it  assigns  to  the  object's  internal 
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pointer;  it  sets  the  bool  to  false  Add  a mennber  function 
test( ) if  the  object's  pointer  is  nonzero,  it  returns  the 
valueoftest(  )called  through  the  pointer.  If  the  pointer  is 
zero,  it  returns  the  bool.  Now  create  five  cpp  files,  each 
of  w hi ch  i ncl udes  the  M I rror header.  The fi  rst  cpp  f i I e 
defines  a global  M irrorobject  using  the  default 
constructor.  The  second  file  declares  the  object  in  the  first 
file  as  extern,  and  defines  a global  M Irrorobject  using 
the  second  constructor,  with  a poi  nter  to  the  fi  rst  object. 
Keep  doing  this  until  you  reach  the  last  file,  which  will 
also  contain  a global  object  definition.  In  that  file,  main( ) 
should  call  thetest(  )function  and  report  the  result.  If  the 
result  is  true  find  out  how  to  change  the  linking  order 
for  your  linker  and  change  it  until  the  result  is  false 

33.  Repair  the  problenn  in  Exercise  32  using  techniqueone 
shown  in  this  book. 

34.  Repair  the  problenn  in  Exercise  32  using  techniquetwo 
shown  in  this  book. 

35.  Without  including  a header  file,  declare  the  function 
puts(  )from  the  Standard  C Library.  Call  this  function 
from  main( ) 


472 


Thinking  in  C+  + 


www.BruceEckel.com 


11:  References  & 
the  Copy- Constructor 

References  are  like  constant  pointers  that  are 
automatically  dereferenced  by  the  compiler. 
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Although  references  also  ©dst  in  Pascal,  the  C++ version  was  taken 
from  the  Algol  language.  They  are  essential  in  C++ to  support  the 
syntax  of  operator  overloading  (see  Chapter  12),  but  they  are  also  a 
general  convenience  to  control  theway  arguments  are  passed  into 
and  out  of  functions. 

This  chapter  will  first  look  briefly  at  the  differences  between 
pointers  in  C and  C++,  then  introduce  references.  But  the  bulk  of 
the  chapter  will  delve  into  a rather  confusing  issueforthenew  C++ 
programmer:  the  copy-constructor,  a special  constructor  (requiring 
references)  that  makes  a new  object  from  an  existing  object  of  the 
same  type.  The  copy-constructor  is  used  by  the  compiler  to  pass 
and  return  objects  by  valuelnto  and  out  of  functions. 

Fi  nal  ly,  the  somewhat  obscure  C-H-po/n ter- to-memter  feature  is 
illuminated. 


Pointers  in  C+-i- 

The  most  i mportant  difference  between  pointers  in  C and  those  in 
C-H-isthat  C-H-is  a more  strongly  typed  language.  This  stands  out 
where  void*  is  concerned.  C doesn't  let  you  casually  assign  a 
pointer  of  one  type  to  another,  but  it  does  allow  you  to  accomplish 
thisthrough  a void*.  Thus, 

bird*  b; 
rock*  r; 
void*  v; 

V = r ; 
b = v; 

Because  this  "feature"  of  C allowsyou  to  quietly  treat  any  type  like 
any  other  type,  it  I eaves  a big  hole  in  the  type  system.  C-H- doesn't 
allow  this;  the  compiler  gives  you  an  error  message,  and  if  you 
real  ly  want  to  treat  one  type  as  another,  you  must  make  it  expl  icit, 
both  to  the  compiler  and  to  the  reader,  using  a cast.  (Chapter  3 
introduced  C-i-+'s  improved  "explicit"  casting  syntax.) 
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References  in  C+  + 

A re^erenceiSi)  is  I ike  a constant  pointer  that  is  automatically 
dereferenced.  It  is  usually  used  for  function  argument  lists  and 
function  return  values.  But  you  can  also  make  a free-standing 
reference.  For  example, 

// : Cll : FreeStandingRef erences . cpp 
#include  <iostream> 
using  namespace  std; 

//  Ordinary  free-standing  reference: 
int  y; 
int&  r = y; 

//  When  a reference  is  created,  it  must 
//be  initialized  to  a live  object. 

//  However,  you  can  also  say: 
const  int&  q = 12;  //  (1) 

//  References  are  tied  to  someone  else's  storage: 


int  X = 0; 

//  (2) 

int&  a = x; 
int  main ( ) { 

//  (3) 

cout  <<  "x  = 
a++ ; 

" <<  X <<  ", 

a = " <<  a <<  endl; 

cout  <<  "x  = 
} ///:- 

" <<  X <<  ", 

a = " <<  a <<  endl; 

In  line(l),  the  compiler  allocatesa  piece  of  storage,  initializes  it 
with  the  value  12,  and  ties  the  reference  to  that  pieceof  storage.  The 
poi nt  i s that  any  reference  must  be  ti ed  to  someone  else's  piece  of 
storage.  When  you  access  a reference,  you're  access!  ng  that  storage. 
Thus,  if  you  write  lines  I ike  (2)  and  (3),  then  incrementing  a is 
actually  increment! ngx,  as  is  shown  in  main( ) Again,  the  easiest 
way  to  think  about  a reference  is  as  a fancy  pointer.  One  advantage 
of  this  "pointer"  isthatyou  never  haveto  wonder  whether  it's  been 
initialized  (the  compiler  enforces  it)  and  how  to  dereference  it  (the 
compiler  does  it). 

There  are  certain  rules  when  using  references: 
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1.  A reference  must  be  initialized  when  it  is  created.  (Pointers 
can  deinitialized  at  any  time.) 

2.  Once  a reference  is  initialized  to  an  object,  it  cannot  be 
changed  to  refer  to  another  object.  (Pointers  can  be  pointed  to 
another  object  at  any  ti  me.) 

3.  You  cannot  have  NULL  references.  You  must  always  be  able 
to  assume  that  a reference  is  connected  to  a legitimate  piece 
of  storage. 

References  in  functions 

The  most  common  place  you'll  see  references  is  as  function 
arguments  and  return  values.  When  a reference  is  used  as  a 
function  argument,  any  modification  to  the  reference /ns/de the 
function  will  cause  changes  to  the  argument  otyts/dethefunction.  Of 
course,  you  could  do  the  something  by  passing  a pointer,  but  a 
reference  has  much  cleaner  syntax.  (You  can  think  of  a reference  as 
nothing  more  than  a syntax  convenience,  if  you  want.) 

If  you  return  a reference  from  a function,  you  must  take  the  same 
care  as  if  you  return  a pointer  from  a function.  Whatever  the 
reference  is  connected  to  shouldn't  go  away  when  thefunction 
returns,  otherwise  you'll  be  referring  to  unknown  memory. 

Here's  an  example: 

//:  Cll : Reference . cpp 
//  Simple  C++  references 

int*  f (int*  x)  { 

(*x) ++; 

return  x;  //  Safe,  x is  outside  this  scope 

} 


int&  g(int&  x)  { 

X++;  //  Same  effect  as  in  f() 

return  x;  //  Safe,  outside  this  scope 

} 
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int&  h()  { 

int  q; 

//!  return  q;  //  Error 
static  int  x; 

return  x;  //  Safe,  x lives  outside  this  scope 

} 

int  main  ( ) { 

int  a = 0; 

f (&a) ; //  Ugly  (but  explicit) 
g(a);  //  Clean  (but  hidden) 

} ///:- 

The  call  tof(  )doesn't  have  the  convenience  and  cleanliness  of 
using  references,  but  it's  clear  that  an  address  is  being  passed.  I n 
the  call  to  g( ),  an  address  is  being  passed  (via  a reference),  but  you 
don't  see  it. 

const  references 

The  reference  argument  in  Referencexppworks  only  when  the 
argument  isa  non-constobject.  If  it  isaconstobject,  thefunction 
g(  )will  not  accept  the  argument,  which  isactually  a good  thing, 
because  the  function  does  modify  the  outside  argument.  If  you 
know  thefunction  will  respect  the  constness  of  an  object,  making 
the  argument  a constreference  will  allow  thefunction  to  beused  in 
all  situations.  This  means  that,  for  built-in  types,  thefunction  will 
not  modify  the  argument,  and  for  user-defined  types,  thefunction 
will  call  only  constmember  functions,  and  won't  modify  any 
publicdata  members. 

The  use  of  const  references  i n f u ncti  on  argu  ments  i s especi  al  I y 
important  because  your  function  may  receive  a temporary  object. 
This  might  have  been  created  as  a return  value  of  another  function 
or  explicitly  by  the  user  of  your  function.  Temporary  objects  are 
always  const  so  if  you  don't  use  a constreference,  that  argument 
won't  be  accepted  by  the  compi  I er.  A s a very  si  mpl  e exampi  e, 

// : Cll : ConstReferenceArguments . cpp 
//  Passing  references  as  const 
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void  f (int&)  { } 
void  g (const  int&)  {} 


int  main  ( ) { 

//  ! f (1) ; //  Error 

g(i) ; 

} ///:- 

The  cal  I to  f(l)  causes  a compi  le-ti  me  error  because  the  compi  ler 
must  f i rst  create  a reference.  1 1 does  so  by  al  I ocati  ng  storage  for  an 
int  initializing  ittooneand  producing  the  address  to  bind  to  the 
reference.  The  storage  must  be  a constbecause  changi  ng  it  would 
make  no  sense -you  can  never  get  your  hands  on  it  again.  With  all 
temporary  objects  you  must  make  the  same  assumption:  that 
they're  inaccessible.  It's  valuable  for  the  compi  ler  to  tel  I you  when 
you're  changing  such  data  becausethe  result  would  be  lost 
information. 

Pointer  references 

In  C,  if  you  want  to  modify  the  contents  of  the  pointer  rather  than 
what  it  points  to,  your  function  declaration  looks  like: 

void  f (int**) ; 

and  you'd  havetotaketheaddressof  the  pointer  when  passing  it 
in: 


int  i = 47; 
int*  ip  = &i; 
f (&ip) ; 

With  references  in  C++,  the  syntax  is  cleaner.  The  function 
argument  becomes  a reference  to  a pointer,  and  you  no  longer  have 
to  take  the  address  of  that  pointer.  Thus, 

//:  Cll : ReferenceToPointer . cpp 
#include  <iostream> 
using  namespace  std; 

void  increment (int*&  i)  { it+;  } 
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<<  i <<  endl; 


int  main  ( ) { 

int*  i = 0; 
cout  <<  "i  = 
increment  ( i ) ; 
cout  <<  "i  = " <<  i <<  endl; 

} ///:- 

By  running  this  program,  you'll  proveto  yourself  that  the  pointer  is 
incremented,  not  what  it  points  to. 

Argument-passing  guidelines 

Your  normal  habit  when  passing  an  argument  to  a function  should 
be  to  pass  by  constreference.  Although  at  first  this  may  seem  like 
only  an  efficiency  concern  (and  you  normally  don't  want  to  concern 
yourself  with  efficiency  tuning  while  you're  designing  and 
assembling  your  program),  there's  more  at  stake:  as  you'll  see  in 
the  remainder  of  the  chapter,  a copy-constructor  is  required  to  pass 
an  object  by  value,  and  this  isn't  always  aval  I able. 

The  efficiency  savings  can  be  substantial  for  such  a simple  habit:  to 
pass  an  argument  by  value  requires  a constructor  and  destructor 
call,  but  if  you're  not  going  to  modify  the  argument  then  passing  by 
constreference  only  needs  an  address  pushed  on  the  stack. 

In  fact,  virtually  the  only  time  passing  an  address /sn't  preferable  is 
when  you're  going  to  do  such  damage  to  an  object  that  passing  by 
value  is  the  only  safe  approach  (rather  than  modifying  the  outside 
object,  someth! ng  the  cal  I er  doesn't  usual  ly  expect).  Thi s is  the 
subject  of  the  next  section. 


The  copy-constructor 

Now  that  you  understand  the  basics  of  the  reference  in  C-H-,  you're 
ready  to  tackle  one  of  the  more  confusi  ng  concepts  i n the  I anguage: 
the  copy-constructor,  often  called  X(X&)("X  of  X ref").  This 
constructor  is  essential  to  control  passing  and  returning  of  user- 
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defined  typesby  value  during  function  calls.  It's  so  important,  in 
fact,  that  the  compi  I er  w i 1 1 automati  cal  I y sy  nthesi ze  a copy- 
constructor  if  you  don't  provide  one  yourself,  as  you  will  see. 

Passing  & returning  by  vaiue 

To  understand  the  need  for  the  copy-constructor,  consider  the  way 
C handles  passing  and  returning  variables  by  value  during  function 
calls.  If  you  declare  a function  and  make  a function  call, 

int  f (int  x,  char  c) ; 
int  g = f (a,  b)  ; 

how  does  the  compiler  know  how  to  pass  and  return  those 
variables?  It  just  knows!  The  range  of  the  types  it  must  deal  with  is 
so  small  - char,  int;  float  doubla  and  their  variations  - that  this 
information  is  built  into  the  compiler. 

If  you  figure  out  how  to  generate  assembly  code  with  your 
compiler  and  determine  the  statements  generated  by  the  function 
call  tof( ),  you'll  get  the  equivalent  of: 

push  b 
push  a 
call  f() 
add  sp, 4 

mov  g,  register  a 

This  code  has  been  cleaned  up  significantly  to  make  it  generic;  the 
expressionsfor  b and  a will  be  different  depending  on  whether  the 
variables  are  global  (in  which  casethey  will  be  _b  and  _a)  or  local 
(the  compi  I er  w i 1 1 i ndex  them  off  the  stack  poi  nter).  Thi  s i s al  so  true 
for  the  expression  forg.  The  appearance  of  the  cal  I tof(  )will 
depend  on  your  name-decoration  scheme,  and  "register  a"  depends 
on  how  the  CPU  registers  are  named  within  your  assembler.  The 
logic  behind  the  code,  however,  will  remai  n the  same. 

In  C and  C-H-,  arguments  are  first  pushed  on  the  stack  from  right  to 
left,  then  the  function  call  is  made.  The  cal  ling  code  is  responsible 
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for  cleaning  the  arguments  off  the  stack  (which  accounts  for  the 
add  sp,4-  But  notice  that  to  pass  the  arguments  by  value,  the 
compiler  simply  pushes  copies  on  the  stack-  it  knows  how  big 
they  are  and  that  pushing  those  arguments  makes  accurate  copies 
of  them. 

The  return  value  of  f(  )is  placed  in  a register.  Again,  the  compiler 
knows  everything  there  is  to  know  about  the  return  value  type 
because  that  type  i s bu  i 1 1 i nto  the  I anguage,  so  the  compi  I er  can 
return  it  by  placing  it  in  a register.  With  the  primitive  data  types  in 
C,  the  simple  act  of  copying  the  bits  of  the  value  is  equivalent  to 
copying  the  object. 

Passing  & returning  iarge  objects 

But  now  consider  user-defined  types.  If  you  create  a class  and  you 
want  to  pass  an  object  of  that  class  by  value,  how  is  the  compi  I er 
supposed  to  know  what  to  do?  This  is  not  a type  built  into  the 
compiler;  it's  a type  you  have  created. 

To  invest!  gate  this,  you  can  start  with  a simple  structure  that  is 
clearly  too  large  to  return  in  registers: 

//:  Cll : PassingBigStructures . cpp 
struct  Big  { 

char  buf [ 100 ] ; 
int  i ; 
long  d; 

} B,  B2; 

Big  bigfun (Big  b)  { 

b.i  = 100;  //  Do  something  to  the  argument 
return  b; 

} 

int  main  ( ) { 

B2  = bigfun (B) ; 

} ///:- 

Decoding  the  assembly  output  is  a little  more  complicated  here 
because  most  compilers  use  "helper"  functions  instead  of  putting 
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all  functionality  inline.  In  main( ) thecall  to  bigfun(  )starts  as  you 
might  guess- the  entire  contents  of  B is  pushed  on  the  stack.  (Here, 
you  might  see  some  compilers  load  registerswith  theaddressof 
the  Big  and  its  size,  then  call  a helper  function  to  push  the  Big  onto 
the  stack.) 

In  the  previous  codefragment,  pushing  the  arguments  onto  the 
stack  was  all  that  was  required  before  making  the  function  call.  In 
PassingBigStructures.cpf]however,  you'll  see  an  additional 
action:  the  address  of  B2  is  pushed  before  making  the  cal  I,  even 
though  it's  obviously  not  an  argument.  To  comprehend  what's 
going  on  here,  you  need  to  understand  the  constraints  on  the 
compiler  when  it's  making  a function  call. 

Function-call  stack  frame 

When  the  compiler  generates  code  for  a function  call,  it  first  pushes 
all  the  arguments  on  the  stack,  then  makes  the  call.  Inside  the 
function,  code  is  generated  to  move  the  stack  pointer  down  even 
farther  to  provide  storage  for  the  function's  local  variables. 

("Down"  is  relative  here;  your  machine  may  increment  or 
decrement  the  stack  pointer  during  a push.)  But  during  the 
assembly-language  CALL,  theCPU  pushes  the  address  in  the 
program  code  where  the  function  call  came  from,  so  the  assembly- 
language  RETURN  can  use  that  address  to  return  to  the  cal  ling 
point.  This  address  is  of  course  sacred,  because  without  it  your 
program  will  get  completely  lost.  Here's  what  the  stack  frame  looks 
I ike  after  the  CALL  and  the  allocation  of  local  variable  storage  in 
thefunction: 


Function  arguments 


Return  address 


Local  variables 
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The  code  generated  for  the  rest  of  the  function  expects  the  memory 
to  belaid  out  exactly  this  way,  so  that  it  can  carefully  pick  from  the 
function  arguments  and  local  variables  without  touching  the  return 
address.  I shall  call  this  block  of  memory,  which  is  everything  used 
by  a function  in  the  process  ofthefunction  call,  the funct/on  frame. 

You  might  think  it  reasonable  to  try  to  return  values  on  the  stack. 
The  compiler  could  simply  push  it,  and  the  function  could  return 
an  offset  to  indicate  how  far  down  in  the  stack  the  return  value 
begins. 

Re-entrancy 

The  problem  occurs  because  functions  in  C and  C++ support 
interrupts;  that  is,  the  languages  are  re-entrant.  They  also  support 
recursive  function  calls.  This  means  that  at  any  point  in  the 
execution  of  a program  an  interrupt  can  occur  without  breaking  the 
program.  Of  course,  the  person  who  writes  the  interrupt  service 
routine  (I  SR)  is  responsible  for  saving  and  restoring  all  the  registers 
that  are  used  in  the  I SR,  but  if  the  I SR  needs  to  use  any  memory 
further  down  on  the  stack,  thismustbeasafethingtodo.  (You  can 
think  of  an  ISR  as  an  ordinary  function  with  no  arguments  and 
void  return  valuethat  saves  and  restores  the  CPU  state.  An  ISR 
function  call  is  triggered  by  some  hardware  event  instead  of  an 
explicit  call  from  within  a program.) 

Now  imagine  what  would  happen  if  an  ordinary  function  tried  to 
return  values  on  the  stack.  You  can't  touch  any  part  of  the  stack 
that's  above  the  return  address,  sothefunction  would  haveto  push 
the  values  below  the  return  address.  But  when  the  assembly- 
language  RETURN  is  executed,  the  stack  pointer  must  be  pointing 
to  the  return  address  (or  right  below  it,  depending  on  your 
machine),  so  right  beforethe  RETURN,  the  function  must  move  the 
stack  pointer  up,  thus  clearing  off  all  its  local  variables.  If  you're 
trying  to  return  values  on  the  stack  below  the  return  address,  you 
become  vulnerable  at  that  moment  because  an  interrupt  could 
come  along.  The  ISR  would  move  the  stack  pointer  down  to  hold 
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its  return  address  and  its  local  variables  and  overwrite  your  return 
value. 

To  solvethisproblenn,  the  caller  could  be  responsible  for  allocating 
the  extra  storage  on  the  stack  for  the  retu  rn  val  ues  before  cal  1 1 ng 
thefunction.  However,  C was  not  designed  this  way,  and  C++ 
must  be  compatible.  Asyou'll  see  shortly,  the  C++ compiler  usesa 
more  effi  cl  ent  scheme. 

Your  next  idea  might  be  to  return  the  value  in  some  global  data 
area,  but  this  doesn't  work  either.  Reentrancy  means  that  any 
function  can  bean  interrupt  routine  for  any  other  function, 
including  the  same  function  you're  currently  insidaThus,  if  you  put 
the  return  value  in  a global  area,  you  might  return  into  the  same 
function,  which  would  overwrite  that  return  value.  The  same  logic 
applies  to  recursion. 

The  only  safe  place  to  return  values  is  in  the  registers,  so  you're 
back  to  the  problem  of  what  to  do  when  the  registers  aren't  large 
enough  to  hoi  d the  retu  rn  val  ue.  The  answer  I s to  push  the  add  ress 
of  the  return  value's  destination  on  the  stack  as  one  of  thefunction 
arguments,  and  let  thefunction  copy  the  return  information 
d i recti  y I nto  the  d esti  nati  on . Thi  s not  onl  y sol  ves  al  I the  probi  ems, 
it's  more  effi  dent.  It's  also  the  reason  that,  in 
PassingBigStructures.cp|]the  compi  ler  pushes  the  address  of  B2 
before  the  cal  I tobigfun(  )in  main( ) If  you  look  at  the  assembly 
output  for  bigfun(  )you  can  see  it  expects  this  hidden  argument 
and  performs  the  copy  to  the  destination  /ns/dethefunction. 

Bitcopy  versus  initialization 

So  far,  so  good.  There's  a workable  process  for  passing  and 
returning  large  simple  structures.  But  notice  that  all  you  have  is  a 
way  to  copy  the  bits  from  one  place  to  another,  which  certainly 
works  fine  for  the  primitive  way  that  C looks  at  variables.  Butin 
C++objects  can  be  much  more  sophisticated  than  a patch  of  bits; 
they  have  meaning.  This  meaning  may  not  respond  well  to  having 
its  bits  copied. 
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Consider  a simple  example:  a class  that  knows  how  many  objects  of 
its  type  exist  at  any  onetime.  From  Chapter  10,  you  know  the  way 
to  do  this  is  by  including  a staticdata  member: 

//:  Cl 1 : HowMany . cpp 

//  A class  that  counts  its  objects 

#include  <fstream> 

#include  <string> 

using  namespace  std; 

of stream  out ( "HowMany . out ")  ; 

class  HowMany  { 

static  int  objectCount; 
public : 

HowMany ( ) { ob jectCount++;  } 

static  void  print (const  strings  msg  = "")  { 

if (msg . size ( ) !=  0)  out  <<  msg  << 

out  <<  "objectCount  = " 

<<  objectCount  <<  endl; 

} 

~HowMany ( ) { 

objectCount — ; 
print ( " ~HowMany ( ) " ) ; 


}; 


int  HowMany :: objectCount  = 0; 

//  Pass  and  return  BY  VALUE: 

HowMany  f (HowMany  x)  { 

X. print ("x  argument  inside  f()"); 
return  x; 

} 

int  main  ( ) { 

HowMany  h; 

HowMany :: print ( "after  construction  of  h"); 

HowMany  h2  = f (h) ; 

HowMany :: print ( "after  call  to  f()"); 

} ///:- 

The  class  H owM  anycontains  a staticint  objectCounfend  a static 

member  function  print(  )to  report  the  value  of  that  objectCount 
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along  with  an  optional  message  argument.  The  constructor 
increments  the  count  each  time  an  object  is  created,  and  the 
destructor  decrements  it. 

The  output,  however,  is  not  what  you  would  expect: 

after  construction  of  h:  objectCount  = 1 
X argument  inside  f () : objectCount  = 1 
-HowManyO  : objectCount  = 0 
after  call  to  f () : objectCount  = 0 
-HowManyO  : objectCount  = -1 
-HowManyO  : objectCount  = -2 

After  h is  created,  the  object  count  is  one,  which  is  fine.  But  after 
the  cal  I tof(  )you  would  expect  to  have  an  object  count  of  two, 
because  h2  is  now  i n scope  as  wel  I . I nstead,  the  count  is  zero,  which 
i nd i cates  someth!  ng  has  gone  horri  bly  wrong.  Thi s i s conf i rmed  by 
the  fact  that  the  two  destructors  at  the  end  make  the  object  count  go 
negative,  something  that  should  never  happen. 

Look  at  the  point  insidef( ),  which  occurs  after  the  argument  is 
passed  by  value.  This  means  the  original  object  h exists  outside  the 
function  frame,  and  there's  an  additional  object  /ns/de the  function 
frame,  which  is  the  copy  that  has  been  passed  by  value.  However, 
the  argument  has  been  passed  using  C's  primitive  notion  of 
bitcopying,  whereas  the  C++ How  M any  cl  ass  requires  true 
initialization  to  maintain  its  integrity,  sothedefault  bitcopy  fails  to 
produce  the  desired  effect. 

W hen  the  I ocal  object  goes  out  of  scope  at  the  end  of  the  cal  I to  f ( ), 
the  destructor  is  cal  led,  which  decrements  objectCount  so  outside 
the fu ncti on,  objectC ount  s zero.  The  creati on  of  h2  i s al so 
performed  using  a bitcopy,  so  the  constructor  isn't  called  there 
either,  and  when  h and  h2go  out  of  scope,  their  destructors  cause 
the  negative  values  of  objectCount 
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Copy-construction 

The  problem  occurs  because  the  compiler  makes  an  assumption 
about  how  to  create  a new  object  from  an  eKisting  object.  When  you 
pass  an  object  by  value,  you  create  a new  object,  the  passed  object 
inside  the  function  frame,  from  an  existing  object,  the  original 
object  outside  the  function  frame.  This  is  also  often  true  when 
returning  an  object  from  a function.  In  the  expression 

I HowMany  h2  = f (h) ; 

h2,  a previously  unconstructed  object,  is  created  from  the  return 
valueof  f( ),  so  again  a new  object  is  created  from  an  existing  one. 

The  compiler's  assumption  isthatyou  want  to  perform  this 
creation  using  a bitcopy,  and  in  many  cases  this  may  work  fine,  but 
in  HowManyit  doesn't  fly  because  the  meaning  of  initialization 
goes  beyond  simply  copying.  Another  common  exampleoccurs  if 
the  cl  ass  contains  pointers  - what  do  they  point  to,  and  should  you 
copy  them  or  should  they  be  connected  to  some  new  piece  of 
memory? 

Fortunately,  you  can  intervene  in  this  process  and  prevent  the 
compiler  from  doing  a bitcopy.  You  do  this  by  defining  your  own 
function  to  be  used  whenever  the  compiler  needsto  makea  new 
object  from  an  existing  object.  Logically  enough,  you're  making  a 
new  object,  so  this  function  is  a constructor,  and  also  logically 
enough,  the  si  ngle  argument  to  this  constructor  has  to  do  with  the 
object  you're  constructi  ng  from.  But  that  object  can't  be  passed  i nto 
the  constructor  by  value  because  you're  trying  to  cfef/nethefunction 
that  handles  passing  by  value,  and  syntactically  it  doesn't  make 
sense  to  pass  a poi  nter  because,  after  al  I , you're  creati  ng  the  new 
object  from  an  existing  object.  H ere,  references  come  to  the  rescue, 
so  you  take  the  reference  of  the  source  object.  This  function  is  called 
the  copy-constructor  and  isoften  referred  to  as  X(X&)i  which  isits 
appearancefor  a class  called  X. 
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If  you  create  a copy-constructor,  the  compiler  will  not  perform  a 
bitcopy  when  creating  a new  object  from  an  existing  one.  It  will 
always  cal  I your  copy-constructor.  So,  if  you  don't  create  a copy- 
constructor,  the  compiler  will  do  something  sensible,  but  you  have 
the  choi  ce  of  taki  ng  over  compi  ete  control  of  the  process. 

Now  it's  possible  to  fix  the  problem  in  HowMany.cpp 

//:  Cll : HowMany2 . cpp 
//  The  copy-constructor 
#include  <fstream> 

#include  <string> 

using  namespace  std; 

of stream  out ( "HowMany2 . out " ) ; 

class  HowMany2  { 

string  name;  //  Object  identifier 

static  int  objectCount; 
public : 

HowMany2 (const  strings  id  = "")  : name (id)  { 

++object Count ; 
print ("HowMany2 () ") ; 

} 

~HowMany2()  { 

— objectCount ; 
print ("~HowMany2 ()  ")  ; 

} 

//  The  copy-constructor: 

HowMany2 (const  HowMany2&  h)  : name (h. name)  { 
name  +=  " copy"; 

++object Count ; 

print ("HowMany2 (const  HowMany2&) ") ; 

} 

void  print (const  strings  msg  = "")  const  { 
if (msg . size ( ) ! = 0 ) 

out  <<  msg  <<  endl; 
out  <<  ' \t ' <<  name  <<  " : " 

<<  "objectCount  = " 

<<  objectCount  <<  endl; 


}; 


int  HowMany2 :: objectCount  = 0; 
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//  Pass  and  return  BY  VALUE: 

HowMany2  f (HowMany2  x)  { 

X. print ("x  argument  inside  f()"); 
out  <<  "Returning  from  f()"  <<  endl; 
return  x; 

} 

int  main  ( ) { 

HowMany2  h("h"); 

out  <<  "Entering  f()"  <<  endl; 

HowMany2  h2  = f (h) ; 

h2. print ("h2  after  call  to  f()"); 

out  <<  "Call  f(),  no  return  value"  <<  endl; 

f (h)  ; 

out  <<  "After  call  to  f()"  <<  endl; 

} ///:- 

There  are  a number  of  new  twists  thrown  in  here  so  you  can  get  a 
better  idea  of  what's  happening.  First,  thestringnameactsasan 
object  identifier  when  information  about  that  object  is  printed,  in 
the  constructor,  you  can  put  an  identifier  string  (usuaiiy  the  name 
of  the  object)  that  iscopied  to  nameusing  the  string  constructor. 
The  defauit  = ""  creates  an  empty  string  The  constructor 
increments  the objectCountas  before,  and  the  destructor 
decrements  it. 

Next  is  the  copy-constructor,  HowM  any2(const  HowM  any2&) 
The  copy-constructor  can  create  a new  object  oniy  from  an  existing 
one,  so  the  existing  object's  name  is  copied  to  nama  foiiowed  by 
theword  "copy"  so  you  can  seewhere  it  came  from,  if  you  iook 
cioseiy,  you'ii  see  that  the  caii  name(h  .name)  n the  constructor 
initiaiizer  iist  isactuaiiy  caiiing  thestringcopy-constructor. 

i nside  the  copy-constructor,  the  object  count  is  i ncremented  just  as 
it  is  insidethenormai  constructor.  This  means  you'ii  now  get  an 
accurate  object  count  when  passing  and  returning  by  vaiue. 

Theprint(  )fu notion  has  been  modified  to  print  out  a message,  the 
object  identifier,  and  the  object  count,  it  must  now  access  the  name 
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data  of  a particular  object,  so  it  can  no  longer  bea  staticmennber 
function. 


Insidemain( ) you  can  seethat  a second  call  tof(  )has  been  added. 
However,  this  cal  I uses  the  common  C approach  of  ignoring  the 
return  value.  But  now  that  you  know  how  thevalue  is  returned 
(that  is,  code /ns/cfethe  function  handles  the  return  process,  putting 
the  result  in  a destination  whose  address  is  passed  as  a hidden 
argument),  you  might  wonder  what  happens  when  the  return 
valueisignored.Theoutputof  the  program  will  throw  some 
illumination  on  this. 

Before  showing  the  output,  here's  a little  program  that  uses 
iostreams  to  add  I ine  numbers  to  any  fi  le: 

//:  Cll : Linenum. cpp 
//{T}  Linenum. cpp 
//  Add  line  numbers 
#include  ".. /require . h" 

#include  <vector> 

#include  <string> 

#include  <fstream> 

#include  <iostream> 

#include  <cmath> 
using  namespace  std; 

int  main(int  argc,  char*  argv [ ] ) { 

requireArgs (argc,  1,  "Usage:  linenum  fileXn" 

"Adds  line  numbers  to  file"); 
ifstream  in(argv[l]); 
assure (in,  argv[l]); 
string  line; 
vector<string>  lines; 

while (getline  (in,  line))  //  Read  in  entire  file 
lines . push_back ( line ) ; 
if (lines . size  ( ) ==  0)  return  0; 
int  num  = 0; 

//  Number  of  lines  in  file  determines  width: 
const  int  width  = int (loglO (lines . size  ()) ) + 1; 
for(int  i = 0;  i < lines . size  () ; i++)  { 

cout . setf  (ios  : : right,  ios:  :adjustfield) ; 
cout .width (width) ; 
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cout  <<  ++num  <<  ")  " <<  lines [i]  <<  endl; 


} III-.- 

The  enti  re  f i I e i s read  i nto  a vector<stri  ng:^ usi  ng  the  same  code 
that  you've  seen  earlier  in  the  book.  When  printing  the  line 
numbers,  we'd  likeall  the  lines  to  be  aligned  with  each  other,  and 
this  requires  adjusting  for  the  number  of  lines  in  the  file  so  that  the 
width  allowed  for  the  line  numbers  is  consistent.  We  can  easily 
determi nethe  number  of  lines  using  vectx>r::size(  Jbut  what  we 
really  need  to  know  is  whether  there  are  more  than  10  lines,  100 
lines,  1,000  lines,  etc.  If  you  take  the  logarithm,  base  10,  of  the 
numberof  lines  in  thefile,  truncate  itto  an  inland  add  one  to  the 
value,  you'll  find  out  the  maximum  width  that  your  line  count  will 
be. 

You'll  noticeacoupleof  strange  cal  Is  inside  thefor  loop:  setf(  )and 
width( ) These  are  ostream  cal  I s that  al  I ow  you  to  control , i n thi  s 
case,  the  justification  and  width  of  the  output.  However,  they  must 
be  cal  I ed  each  ti  me  a I i ne  i s output  and  that  i s why  they  are  i nsi  de 
the  for  I oop.  Vol  u me  2 of  thi  s book  has  an  enti  re  chapter  expl  ai  ni  ng 
iostreams  that  will  tell  you  more  about  these  cal  Is  as  well  as  other 
ways  to  control  iostreams. 

When  Linenum.cppis  applied  to  How  Many  2.oufthe  result  is 

1 ) HowMany2 ( ) 

2)  h:  objectCount  = 1 

3 ) Entering  f ( ) 

4)  HowMany2 (const  HowMany2&) 

5)  h copy:  objectCount  = 2 

6)  X argument  inside  f() 

7)  h copy:  objectCount  = 2 

8)  Returning  from  f() 

9)  HowMany2 (const  HowMany2&) 

10)  h copy  copy:  objectCount  = 3 

1 1 ) ~HowMany2 ( ) 

12)  h copy:  objectCount  = 2 

13)  h2  after  call  to  f() 

14)  h copy  copy:  objectCount  = 2 
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15)  Call  f(),  no  return  value 

16)  HowMany2 (const  HowMany2&) 

17)  h copy:  objectCount  = 3 

18)  X argument  inside  f() 

19)  h copy:  objectCount  = 3 

20)  Returning  from  f() 

21)  HowMany2 (const  HowMany2&) 

22)  h copy  copy:  objectCount  = 4 

23)  ~HowMany2() 

24)  h copy:  objectCount  = 3 

25)  ~HowMany2() 

26)  h copy  copy:  objectCount  = 2 

27)  After  call  to  f() 

28)  ~HowMany2() 

29)  h copy  copy:  objectCount  = 1 

30)  ~HowMany2() 

31)  h:  objectCount  = 0 

As  you  would  ©cpect,  the  first  thing  that  happens  is  that  the  normal 
constructor  is  cal  led  for  h,  which  increments  the  object  count  to 
one.  But  then,  asf( ) is  entered,  the  copy-constructor  is  quietly 
called  by  the  compiler  to  perform  the  pass-by-value.  A new  object 
is  created,  which  isthecopy  of  h (thusthename  "h  copy")  inside 
thefunction  frame  of  f( ),  so  the  object  count  becomes  two,  courtesy 
of  the  copy-constructor. 

Line  eight  indicates  the  beginning  of  the  return  fromf( ).  But  before 
the  local  variable  "h  copy"  can  be  destroyed  (it  goes  out  of  scope  at 
the  end  of  thefunction),  it  must  be  copied  into  the  return  value, 
which  happens  to  behZ  A previously  unconstructed  object  (h2)  is 
created  from  an  existing  object  (the  local  variable  insidef( )),  so  of 
course  the  copy-constructor  is  used  again  in  line  nine.  Now  the 
name  becomes  "h  copy  copy"  for  hZs  identifier  because  it's  being 
copied  from  the  copy  that  isthelocal  object  insidef( ).  After  the 
object  is  returned,  but  before  the  function  ends,  the  object  count 
becomes  temporarily  three,  but  then  the  local  object  "h  copy"  is 
destroyed.  After  the  cal  I tof( ) completes  in  line  13,  there  are  only 
two  objects,  h and  h2,  and  you  can  seethat  h2did  indeed  end  up  as 
"h  copy  copy." 
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Temporary  objects 

Line  15  begins  the  call  tof(h),  thistime  ignoring  the  return  value. 
You  can  see  in  line  16  that  the  copy-constructor  iscalled  justas 
before  to  pass  the  argument  in.  And  also,  as  before,  line  21  shows 
the  copy-constructor  iscalled  for  the  return  value.  Butthecopy- 
constructor  must  have  an  address  to  work  on  as  its  destination  (a 
th  i s poi  nter) . W here  d oes  th I s ad  d ress  come  from? 

It  turns  out  the  compiler  can  create  a temporary  object  whenever  it 
needs  one  to  properly  evaluate  an  expression.  In  this  case  it  creates 
one  you  don't  even  see  to  act  as  the  destination  for  the  ignored 
return  valueof  f( ).  The  lifetime  of  this  temporary  object  Isas  short 
as  possible  so  the  landscape  doesn't  get  cluttered  up  with 
temporaries  waiting  to  be  destroyed  and  taking  up  valuable 
resources.  In  some  cases,  the  temporary  might  immediately  be 
passed  to  another  function,  but  in  this  case  it  isn't  needed  after  the 
function  call,  so  as  soon  as  the  function  call  ends  by  calling  the 
destructor  for  the  local  object  (lines  23  and  24),  the  temporary  object 
is  destroyed  (lines  25  and  26). 

Finally,  in  lines  28-31,  the h2  object  is  destroyed,  followed  by  h,  and 
the  object  count  goes  correctly  back  to  zero. 

Default  copy-constructor 

Because  the  copy-constructor  implements  pass  and  return  by  value, 
it's  i mportant  that  the  compi  I er  creates  one  for  you  i n the  case  of 
simple  structures-  effectively,  the  something  it  does  in  C. 

However,  all  you'veseen  so  far  isthedefault  primitive  behavior:  a 
bitcopy. 

When  more  complex  types  are  involved,  the  C-H-compi  ler  wi  1 1 sti  1 1 
automatically  create  a copy-constructor  if  you  don't  makeone. 
Again,  however,  a bitcopy  doesn't  make  sense,  because  it  doesn't 
necessarily  implement  the  proper  meaning. 
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H ere's  an  ©campl  e to  show  the  more  i ntel  I i gent  approach  the 
compiler  takes.  Suppose  you  create  a new  cl  ass  composed  of  objects 
of  several  exi  sti  ng  cl  asses.  Thi  s i s cal  I ed,  appropri  atel  y enough, 
composition,  and  it's  one  of  the  ways  you  can  make  new  classes  from 
existing  classes.  Now  take  the  roleof  a naive  user  who's  trying  to 
solvea  problem  quickly  by  creating  a new  class  this  way.  You  don't 
know  about  copy-constructors,  so  you  don't  create  one.  The 
example  demonstrates  what  the  compi  ler  does  whi  I e creating  the 
default  copy-constructor  for  your  new  class: 

// : Cll : Def aultCopyConstructor . cpp 
//  Automatic  creation  of  the  copy-constructor 
#include  <iostream> 

#include  <string> 
using  namespace  std; 

class  WithCC  { //  With  copy-constructor 
public : 

//  Explicit  default  constructor  required: 

WithCC 0 {} 

WithCC (const  WithCC&)  { 

cout  <<  "WithCC (WithCC& ) " <<  endl; 


}; 


class  WoCC  { //  Without  copy-constructor 
string  id; 
public : 

WoCC  (const  Strings  ident  = "")  : id(ident)  {} 

void  print  (const  strings  msg  = "")  const  { 
if (msg . size ( ) !=  0)  cout  <<  msg  << 

cout  <<  id  <<  endl; 


}; 


class  Composite  { 

WithCC  withcc;  //  Embedded  objects 
WoCC  wocc; 
public : 

Composite  0 : wocc ( "Composite ()" ) {} 

void  print  (const  strings  msg  = "")  const  { 
wocc. print (msg) ; 
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} 


}; 


int  main  ( ) { 

Composite  c; 

c . print ( "Contents  of  c"); 

cout  <<  "Calling  Composite  copy-constructor" 

<<  endl; 

Composite  c2  = c;  //  Calls  copy-constructor 
c2 . print ( "Contents  of  c2"); 

} ///:- 

The  class  WithCC  contains  a copy-constructor,  which  simply 
announces  that  it  has  been  called,  and  this  brings  up  an  interesting 
issue.  In  the  cl  ass  Composite  an  objectof  WithCC  is  created  using 
a default  constructor.  If  there  were  no  constructors  at  all  in 
WithCC,  the  compiler  would  automatically  create  a default 
constructor,  which  would  do  nothing  in  this  case.  However,  if  you 
add  a copy-constructor,  you've  told  the  compiler  you're  going  to 
handle  constructor  creation,  so  it  no  longer  creates  a default 
constructor  for  you  and  will  complain  unless  you  explicitly  create  a 
default  constructor  as  was  done  for  WithCC. 

The  class  WoCC  has  no  copy-constructor,  but  its  constructor  will 
store  a message  in  an  internal  stringthat  can  be  printed  out  using 
print( ) This  constructor  is  explicitly  called  in  Composites 
constructor  initializer  list  (briefly  introduced  in  Chapter  8 and 
covered  fully  in  Chapter  14).  The  reason  for  this  becomes  apparent 
later. 

The  class  Compositehas  member  objects  of  both  WithCC  and 
WoCC  (note the  embedded  object  wocc is  initialized  in  the 
constructor-initializer  list,  as  it  must  be),  and  no  explicitly  defined 
copy-constructor.  However,  in  main(  )an  object  is  created  using  the 
copy-constructor  in  the  definition: 

Composite  c2  = c; 
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The  copy-constructor  for  Compositeis  created  automatically  by  the 
compiler,  and  theoutput  of  the  program  reveals  the  way  that  it  is 
created: 

Contents  of  c:  Composite () 

Calling  Composite  copy-constructor 
WithCC (WithCC&) 

Contents  of  c2 : Composite () 

To  create  a copy-constructor  for  a class  that  uses  composition  (and 
inheritance,  which  is  introduced  in  Chapter  14),  the  compiler 
recursively  cal  Is  the  copy-constructors  for  all  the  member  objects 
and  baseclasses.  Thatis,  ifthe  member  object  also  contains  another 
object,  its  copy-constructor  is  also  called.  So  in  this  case,  the 
compi  ler  cal  Is  the  copy-constructor  for  WithC  C.  The  output  shows 
this  constructor  being  called.  Because  WoCC  has  no  copy- 
constructor,  the  compi  ler  creates  one  for  it  that  just  performs  a 
bitcopy,  and  cal  Is  that  inside  the  Compositecopy-constructor.  The 
call  toComposite::print(  )n  main  shows  that  this  happens  because 
the  contents  of  c2.woccare  identical  to  the  contents  of  c.wocc  The 
process  the  compi  ler  goes  through  to  synthesize  a copy-constructor 
is  called  memberwise  initialization. 

It's  always  best  to  create  your  own  copy-constructor  I nstead  of 
letting  the  compi  ler  do  it  for  you.  This  guarantees  that  it  wi  1 1 be 
under  your  control. 

Alternatives  to  copy-construction 

At  this  point  your  head  may  be  swimming,  and  you  might  be 
wondering  how  you  could  have  possibly  written  a working  class 
without  knowing  about  the  copy-constructor.  But  remember:  You 
need  a copy-constructor  only  if  you're  going  to  pass  an  object  of 
your  class  by  value.  If  that  never  happens,  you  don't  need  a copy- 
constructor. 
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Preventing  pass-by-value 

"But,"  you  say,  "if  I don't  make  a copy-constructor,  the  compiler 
will  create onefor  me.  So  how  do  I know  that  an  object  will  never 
be  passed  by  value?" 

There's  a simple  technique  for  preventing  pass-by-value:  declarea 
privatecopy-constructor.  You  don't  even  need  to  create  a 
definition,  uni  ess  one  of  your  member  functions  or  a friend 
function  needsto  perform  a pass-by-value.  If  the  user  tries  to  pass 
or  return  the  object  by  val  ue,  the  compi  ler  wi  1 1 produce  an  error 
message  because  the  copy-constructor  is  private  It  can  no  longer 
create  a default  copy-constructor  because  you've  explicitly  stated 
that  you're  taki  ng  over  that  job. 

Here's  an  example: 

//:  Cll : NoCopyConstruction . cpp 
//  Preventing  copy-construction 

class  NoCC  { 
int  i ; 

NoCC  (const  NoCC&);  //  No  definition 
public : 

NoCC(int  ii  = 0)  : i(ii)  {} 

}; 


void  f (NoCC) ; 

int  main  ( ) { 

NoCC  n; 

//!  f (n) ; //  Error:  copy-constructor  called 

//!  NoCC  n2  = n;  //  Error:  c-c  called 
//!  NoCC  n3  (n) ; //  Error:  c-c  called 
} ///:- 

Notice  the  use  of  the  more  general  form 

NoCC (const  NoCC&); 

using  the  const 
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Functions  that  modify  outside  objects 

Reference  syntax  is  nicer  to  use  than  pointer  syntax,  yet  it  clouds 
the  meaning  for  the  reader.  For  example,  in  the  iostreams  library 
one  overloaded  version  oftheget(  )fu notion  takes  a char&  as  an 
argument,  and  the  whole  point  of  the  function  isto  modify  its 
argument  by  inserting  the  result  of  the  get(  j However,  when  you 
read  code  using  thisfunction  it's  not  immediately  obvious  to  you 
that  the  outside  object  is  being  modified: 

char  c; 
cin . get (c) ; 

Instead,  thefunction  call  looks  likea  pass- by- value,  which  suggests 
the  outside  object  is  not  modified. 

Because  of  this,  it's  probably  safer  from  a code  maintenance 
stand poi  nt  to  use  pointers  when  you're  passi  ng  the  address  of  an 
argument  to  modify.  If  you  always  pass  addresses  as  const 
references  e)(cept  when  you  intend  to  modify  the  outside  object  via 
the  address,  where  you  pass  by  non-constpointer,  then  your  code 
i s far  easi  er  for  the  read er  to  fol  I ow . 


Pointers  to  members 

A pointer  is  a variable  that  holdstheaddress  of  some  location.  You 
can  change  what  a pointer  selects  at  runtime,  and  the  destination  of 
the  pointer  can  be  either  data  or  a function.  TheC-H- 
pointer-to-member  foWo\Nsth\s  same  concept,  except  that  what  it 
selects  is  a location  insidea  class.  The  dilemma  here  is  that  a 
pointer  needs  an  address,  butthereisno  "address"  insidea  class; 
selecting  a member  of  a class  means  offsetting  into  that  class.  You 
can't  produce  an  actual  address  until  you  combine  that  offset  with 
the  starting  address  of  a particular  object.  The  syntax  of  pointers  to 
members  requires  that  you  select  an  object  at  the  same  time  you're 
dereferencing  the  poi nter  to  member. 
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To  understand  this  syntax,  consider  a si mplestructure,  with  a 
pointer  sp  and  an  object  so  for  this  structure.  You  canseiect 
mennbers  with  the  syntax  shown: 

//:  Cl 1 : SimpleStructure . cpp 
struct  Simple  { int  a;  }; 
int  main  ( ) { 

Simple  so,  *sp  = &so; 

sp->a; 

so . a; 

} ///:- 

Now  suppose  you  have  an  ordinary  pointer  to  an  integer,  ip.  To 
access  what  ip  is  pointing  to,  you  dereference  the  pointer  with  a 

*ip  = 4; 

Finaiiy,  consider  what  happens  if  you  havea  pointer  that  happens 
to  point  to  something  inside  ad  ass  object,  even  if  it  does  in  fact 
represent  an  offset  i nto  the  object.  T o access  what  it's  poi  nti  ng  at, 
you  must  dereference  it  with  *.  But  it's  an  offset  into  an  object,  so 
you  must  ai so  refer  to  that  parti cuiar  object.  Thus,  the*  is  combined 
with  the  object  dereference.  So  the  new  syntax  becomes  - >*  for  a 
poi  nter  to  an  object,  and  .*  for  the  object  or  a reference,  i i ke  thi  s: 

ob jectPointer->*pointerToMember  = 47; 
object . *pointerToMember  = 47; 

Now,  what  is  the  syntax  for  defining  pointerToMembef  Like  any 
pointer,  you  have  to  say  what  type  it's  pointing  at,  and  you  use  a* 
in  the  definition.  The  oniy  difference  is  that  you  must  say  what 
ciass  of  objects  this  pointer-to-member  is  used  with.  Of  course,  this 
isaccompiished  with  the  name  of  the  ciass  and  the  scope  resoiuti on 
operator.  Thus, 

int  ObjectClass: : *pointerToMember ; 

defines  a pointer-to-member  variabiecaiied  pointeiToM  embeithat 
points  to  any  intinsideObjectClassYou  can  aiso  initiaiizethe 
poi  nter-to-member  when  you  define  it  (or  at  any  other  ti  me): 
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int  Ob jectClass : : *pointerToMember  = &Ob jectClass : : a; 

There  is  actually  no  "address"  of  ObjectClass::abecause  you're  just 
referri  ng  to  the  cl  ass  and  not  an  object  of  that  cl  ass.  Thus, 
&ObjectClass::a:an  be  used  only  as  pointer-to-member  syntax. 

H ere's  an  example  that  shows  how  to  create  and  use  poi  nters  to 
data  members: 

//:  Oil : PointerToMemberData . cpp 
#include  <iostream> 
using  namespace  std; 

class  Data  { 
public : 

int  a,  b,  c; 

void  print  0 const  { 

cout  <<  "a  = " <<  a <<  ",  b = " <<  b 
<<  ",  c = " <<  c <<  endl; 


}; 


int  main  ( ) { 

Data  d,  *dp  = &d; 

int  Data::*pmlnt  = &Data::a; 

dp->*pmlnt  = 47; 

pmint  = &Data::b; 

d. *pmlnt  = 48; 

pmint  = &Data::c; 

dp->*pmlnt  = 49; 

dp->print ( ) ; 

} ///:- 

Obviously,  these  are  too  awkward  to  use  anywhere  except  for 
special  cases  (which  isexactly  what  they  were  intended  for). 

Also,  poi  nters  to  members  are  quite  limited:  they  can  be  assigned 
only  to  a specific  location  inside  a class.  You  could  not,  for  example, 
increment  or  compare  them  as  you  can  with  ordinary  pointers. 
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Functions 

A similar  exercise  produces  the  pointer-to-member  syntax  for 
member  functions.  A pointer  to  a function  (introduced  at  the  end  of 
Chapter  3)  is  defined  likethis: 

I int  (*fp) (float) ; 

The  parentheses  around  (*f  p)are  necessary  to  force  the  compi  ler  to 
evaluate  the  definition  properly.  Without  them  this  would  appear 
to  be  a function  that  returns  an  int*. 

Parentheses  also  play  an  important  role  when  defining  and  using 
pointers  to  member  functions.  If  you  have  a function  inside  a cl  ass, 
you  define  a pointer  to  that  member  function  by  inserting  the  cl  ass 
name  and  scope  resolution  operator  into  an  ordinary  function 
pointer  definition: 

//:  Cll : PmemFunDef inition . cpp 
class  Siinple2  { 
public : 

int  f (float)  const  { return  1;  } 

}; 

int  (Siinple2  : : *fp)  (float)  const; 

int  (Siinple2  ::  *fp2)  (float)  const  = &Siinple2  : : f ; 

int  main  ( ) { 

fp  = &Simple2::f; 

} ///:- 

In  the  definition  for  fp2you  can  see  that  a pointer  to  member 
function  can  also  be  initialized  when  it  is  created,  or  at  any  other 
time.  Unl  ike  non-member  functions,  the  & isnotoptional  when 
taking  theaddressof  a member  function.  However,  you  can  give 
thefunction  identifier  without  an  argument  list,  because  overload 
resolution  can  be  determined  by  the  type  of  the  pointer  to  member. 

An  example 

The  val  ue  of  a poi  nter  is  that  you  can  change  what  it  poi  nts  to  at 
runtime,  which  provides  an  important  flexibility  in  your 
programming  because  through  a pointer  you  can  selector  change 
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behavior  at  runtime.  A poi nter-to-member  is  no  different;  it  allows 
you  to  choose  a member  at  runtime.  Typically,  your  classes  will 
only  have  member  functions  publicly  visible  (data  members  are 
usually  considered  part  of  the  underlying  implementation),  so  the 
following  example  selects  member  functions  at  runtime. 

/ / : Cl 1 : PointerToMember Function . cpp 
#include  <iostream> 
using  namespace  std; 

class  Widget  { 
public : 

void  f(int)  const  { cout  <<  "Widget :: f () \n" ; } 

void  g(int)  const  { cout  <<  "Widget :: g () \n" ; } 

void  h(int)  const  { cout  <<  "Widget :: h () \n" ; } 

void  i(int)  const  { cout  <<  "Widget :: i () \n" ; } 

}; 

int  main  ( ) { 

Widget  w; 

Widget*  wp  = &w; 

void  (Widget :: *pmem)  (int)  const  = &Widget::h; 

(w . *pmem) ( 1 ) ; 

(wp->*pmem)  (2)  ; 

} ///:- 

Of  course,  it  isn't  particularly  reasonableto  expect  the  casual  user 
to  create  such  complicated  expressions.  If  the  user  must  directly 
manipulate  a poi  nter-to-member,  then  atypedefisin  order.  To 
really  clean  things  up,  you  can  use  the  poi  nter-to-member  as  part  of 
the  internal  implementation  mechanism.  Here's  the  preceding 
example  using  a poi  nter-to-member  /ns/cfetheclass.  All  the  user 
needs  to  do  is  pass  a number  in  to  select  a function.^ 

// : Cll : PointerToMemberFunction2 . cpp 
#include  <iostream> 
using  namespace  std; 


^Thanks  to  Owen  Mortensen  for  this  example 
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class  Widget  { 

void  f(int)  const  { cout  <<  "Widget :: f () \n" ; } 

void  g(int)  const  { cout  <<  "Widget :: g () \n" ; } 

void  h(int)  const  { cout  <<  "Widget :: h () \n" ; } 

void  i(int)  const  { cout  <<  "Widget :: i () \n" ; } 

enum  { cnt  =4  } ; 

void  (Widget :: *fptr [cnt] ) (int)  const; 
public : 

Widget  ( ) { 

fptr[0]  = &Widget::f;  //  Full  spec  required 
fptr[l]  = &Widget::g; 
fptr[2]  = &Widget::h; 
fptr[3]  = &Widget::i; 


void  select (int  i,  int  j)  { 

if(i  < 0 II  i >=  cnt)  return; 
(this->*fptr  [i] ) ( j)  ; 

} 

int  count  0 { return  cnt;  } 


int  main  ( ) { 

Widget  w; 

for  (int  i = 0;  i < w.countO;  i++) 
w. select  (i,  47) ; 

} ///:- 

In  theclassinterfacean(d  in  main( ) you  can  see  that  the  entire 
implementation,  including  the  functions,  has  been  hidden  away. 
The  code  must  even  askforthecount(  )of  functions.  This  way,  the 
class  implementer  can  change  the  quantity  of  functions  in  the 
underlying  implementation  without  affecting  the  code  where  the 
class  is  used. 

The  initialization  of  the  pointers-to-members  in  the  constructor 
may  seem  overspecified.  Shouldn't  you  beableto  say 

fptr[l]  = &g; 

because  the  nameg  occurs  in  the  member  function,  which  is 
automatically  in  the  scope  of  the  class?  The  problem  isthisdoesn't 
conform  to  the  pointer-to-member  syntax,  which  is  required  so 
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everyone,  especially  the  compiler,  can  figure  out  what's  going  on. 
Similarly,  when  thepointer-to-member  is  dereferenced,  it  seems 
like 


(this->*fptr  [i] ) ( j)  ; 

is  also  over-specified;  this  looks  redundant.  Again,  the  syntax 
requires  that  a pointer-to-member  always  be  bound  to  an  object 
when  it  is  dereferenced. 


Summary 

Pointers  in  C-H- are  almost  identical  to  pointers  in  C,  which  isgood. 
Otherwise,  a lot  of  C code  wouldn't  compile  properly  under  C-H-. 
The  only  compile-time  errors  you  will  produce  occur  with 
dangerous  assignments.  If  these  are  in  fact  what  are  i ntended,  the 
compile-time  errors  can  be  removed  with  a simple  (and  explicit!) 
cast. 

C-H-alsoaddsthereferencefrom  Algol  and  Pascal,  which  is  I ike  a 
constant  pointer  that  is  automatically  dereferenced  by  the  compiler. 
A reference  holds  an  address,  but  you  treat  it  I ike  an  object. 
References  are  essential  for  clean  syntax  with  operator  overloading 
(the  subject  of  the  next  chapter),  but  they  also  add  syntactic 
convenience  for  passing  and  returning  objects  for  ordinary 
functions. 

The  copy-constructor  takes  a reference  to  an  existing  object  of  the 
same  type  as  its  argument,  and  it  is  used  to  create  a new  object 
from  an  existing  one.  The  compiler  automatically  cal  Is  the  copy- 
constructor  when  you  pass  or  return  an  object  by  value.  Although 
the  compiler  will  automatically  create  a copy-constructor  for  you,  if 
you  think  one  will  be  needed  for  your  class,  you  should  always 
define  it  yourself  to  ensure  that  the  proper  behavior  occurs.  If  you 
don't  want  the  object  passed  or  returned  by  value,  you  should 
create  a private  copy-constructor. 
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Poi  nters-to-members  have  the  same  fu  ncti  onal  i ty  as  ord  i nary 
pointers:  You  can  choose  a particular  region  of  storage  (data  or 
function)  at  runtime.  Poi  nters-to-members  just  happen  to  work 
with  class  members  instead  of  with  global  data  or  functions.  You 
get  the  programmi  ng  f I exi  bi  I i ty  that  al  I ows  you  to  change  behavi  or 
at  runtime. 


Exercises 

Solutions  to  selected  exercises  can  be  found  in  the  electronic  document  TheThinking  in  C++ Annotated 
Solution  Guide,  aval  I able  for  a small  feefromwww.BruceEckel.com. 

1.  Turn  the  "bird  & rock"  code  fragment  at  the  beginning  of 
this  chapter  into  a C program  (using  struck  for  the  data 
types),  and  show  that  it  compiles.  Now  try  to  compile  it 
with  the  C-H- compiler  and  see  what  happens. 

2.  Take  the  code  fragments  in  the  beginning  of  the  section 
titled  "References  in  C-H-"  and  put  them  into  a main( ) 
Add  statements  to  print  output  so  that  you  can  proveto 
you rself  that  references  are  I i ke  poi  nters  that  are 
automatically  dereferenced. 

3.  Write  a program  in  which  you  try  to  (1)  Create  a 
reference  that  is  not  initialized  when  it  is  created.  (2) 
Change  a reference  to  refer  to  another  object  after  it  is 
initialized.  (3)  Createa  NULL  reference. 

4.  Write  a function  that  takes  a pointer  argument,  modifies 
what  the  pointer  points  to,  and  then  returns  the 
destination  of  the  pointer  as  a reference. 

5.  Createa  class  with  some  member  functions,  and  make 
that  the  object  that  is  poi  nted  to  by  the  argument  of 
Exerd  se  4.  M ake  the  poi  nter  a constand  make  some  of 
the  member  fu  ncti  onsconstand  prove  that  you  can  only 
cal  I the  const  member  f u ncti  ons  i nsi  d e you  r f u ncti  on . 

M ake  the  argu  ment  to  you  r f u ncti  on  a reference  i nstead 
of  a poi  nter. 
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6.  Take  the  code  fragments  at  the  beginning  of  the  section 
titied  "Pointer  references"  and  turn  them  into  a program. 

7.  Create  a function  that  takes  an  argument  of  a referenceto 
a pointer  to  a pointer  and  modifies  that  argument.  In 
main( ) call  the  function. 

8 . C reate  a f u ncti  on  that  takes  a char&  argu  ment  and 
modifies  that  argument.  In  main( ) print  out  a char 
variable,  call  your  function  for  that  variable,  and  print  it 
out  again  to  proveto  yourself  that  it  has  been  changed. 
How  does  this  affect  program  readability? 

9.  Writeaclassthathasaconstmember function  and  a 
non-const  member  function.  Write  three  functionsthat 
take  an  object  of  that  class  as  an  argument;  the  first  takes 
it  by  value,  the  second  by  reference,  and  the  third  by 
const  reference.  Inside  the  functions,  try  to  call  both 
memberfunctionsof  your  classand  explain  the  results. 

10.  (Somewhat  challenging)  Writea  simplefunction  that 
takes  an  intas  an  argument,  increments  the  value,  and 
returns  it.  In  main( ) call  your  function.  Now  discover 
how  your  compiler  generates  assembly  codeand  trace 
through  the  assembly  statements  so  that  you  understand 
how  arguments  are  passed  and  returned,  and  how  local 
variables  are  i ndexed  off  the  stack. 

11.  Write  a function  that  takes  as  its  arguments  a char,  int; 
float;  and  double  Generate  assembly  code  with  your 
compiler  and  find  the  statements  that  push  the 

argu  ments  on  the  stack  before  a f u ncti  on  cal  I . 

12.  Write  a function  that  returns  a double  Generate 
assembly  code  and  determi  ne  how  the  val ue  is  returned. 

13.  Produce  assembly  codefor  Passings  I gStructuresxpp 
Trace  through  and  demystify  the  way  your  compiler 
generates  code  to  pass  and  return  large  structures. 

14.  Write  a simple  recursive  function  that  decrements  its 
argument  and  returns  zero  if  the  argument  becomes  zero, 
otherwise  it  calls  itself.  Generate  assembly  codefor  this 
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function  and  ©(plain  how  the  way  that  the  assennbly  code 
is  created  by  the  compi  ler  supports  recursion. 

15.  Writecodeto  provethatthecompiler  automatically 
synthesizes  a copy-constructor  if  you  don't  create  one 
yourself.  Provethat  the  synthesized  copy-constructor 
performs  a bitcopy  of  primitive  types  and  cal  Is  the  copy- 
constructor  of  user-defined  types. 

16.  Write  a class  with  a copy-constructor  that  announces 
itself  to  cout  N ow  create  a function  that  passes  an  object 
of  your  new  cl  ass  in  by  value  and  another  one  that 
creates  a local  object  of  your  new  class  and  returns  it  by 
value.  Call  these  functions  to  proveto  yourself  that  the 
copy-constructor  is  indeed  quietly  called  when  passing 
and  returning  objects  by  value. 

17.  C reate  a cl  ass  that  contai  ns  a dou bl  e*.  The  constructor 
initializes thedouble*by  calling  new  doubleand 
assigning  a value  to  the  resulting  storage  from  the 
constructor  argument.  The  destructor  prints  the  value 
that's  pointed  to,  assignsthatvalueto-1,  callsdeletefor 
the  storage,  and  then  sets  the  poi  nter  to  zero.  N ow  create 
a function  that  takes  an  object  of  your  class  by  value,  and 
call  thisfunction  in  main( ) What  happens?  Fix  the 
problem  by  writing  a copy-constructor. 

18.  Create  a class  with  a constructor  that  looks  I ike  a copy- 
constructor,  but  that  has  an  extra  argument  with  a 
default  value.  Show  that  this  is  still  used  as  the  copy- 
constructor. 

19.  Create  a class  with  a copy-constructor  that  announces 
itself.  M akea  second  class  containing  a member  object  of 
thefirst  class,  but  do  not  create  a copy-constructor.  Show 
that  the  synthesized  copy-constructor  in  the  second  class 
automatically  cal  Is  the  copy-constructor  of  thefi  rst  class. 

20.  Createa  very  simple  cl  ass,  and  a function  that  returns  an 
object  of  that  class  by  value.  Create  a second  function  that 
takes  a reference  to  an  object  of  you  r cl  ass.  Cal  I the  f i rst 
function  as  the  argument  of  the  second  function,  and 
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demonstratethat  the  second  function  must  use  a const 
reference  as  its  argument. 

21.  Create  a simple  class  without  a copy-constructor,  and  a 
simple  function  that  takes  an  object  of  that  class  by  value. 
Now  change  your  class  by  adding  a privatedeclaration 
(only)  for  the  copy-constructor.  Explain  what  happens 
when  your  function  is  compiled. 

22.  This  exercise  creates  an  alternativeto  using  thecopy- 
constructor.  CreateaclassXand  declare  (but  don't 
define)  a privatecopy-constructor.  Makea  publicclone( ) 
function  as  a constmember  function  that  returns  a copy 
of  the  object  that  is  created  using  new.  Now  write  a 
function  that  takes  as  an  argument  a const  X&  and  clones 
a local  copy  that  can  be  modified.  The  draw  back  to  this 
approach  isthatyou  are  responsible  for  explicitly 
destroying  the  cloned  object  (using  delete^  when  you're 
done  with  it. 

23.  Explain  what's  wrong  with  both  Mem.cppand 
M emT estcppfrom  Chapter  7.  Fix  the  problem. 

24.  Create  a class  containing  a doubleand  aprint(  )function 
that  prints  the  double  In  main( ) create  poi  nters  to 
members  for  both  the  data  member  and  thefunction  in 
your  class.  Create  an  object  of  your  class  and  a poi  nter  to 
that  object,  and  man!  pul  ate  both  cl  ass  elements  via  your 
poi  nters  to  members,  using  both  the  object  and  the 

poi  nter  to  the  object. 

25.  C reate  a cl  ass  contai  ni  ng  an  array  of  i nt  Can  you  i ndex 
through  this  array  using  a pointer  to  member? 

26.  Modify  PmemFunDefinition.cp|lDy  adding  an 
overloaded  member  function  f(  )(you  can  determinethe 
argument  1 1st  that  causes  the  overload).  Now  makea 
second  poi  nter  to  member,  assign  it  to  the  overloaded 
version  offO,  and  call  thefunction  through  that  pointer. 
How  does  the  overload  resolution  happen  inthiscase? 

27.  Start  with  FunctionTable.cp(from  Chapter  3.  Create  a 
class  that  contains  a vector  of  pointers  to  functions,  with 
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add(  )and  remove(  )member  functions  to  add  and 
remove  pointersto  functions.  Add  arun(  )function  that 
moves  through  the  vectorand  calls  all  of  the  functions. 

28.  Modify  the  above  Exercise  27  so  that  it  works  with 
pointersto  member  functions  instead. 
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12:  Operator  Overloading 

Operator  overloading  is  just  "syntactic  sugar,"  which 
means  it  is  simply  another  way  for  you  to  make  a 
function  call. 
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The  d ifference  i s that  the  argu  merits  for  thi  s fu  ncti  on  don't  appear 
inside  parentheses,  but  instead  they  surround  or  are  next  to 
characters  you've  always  thought  of  as  immutable  operators. 

There  are  two  differences  between  the  use  of  an  operator  and  an 
ordinary  function  call.  The  syntax  is  different;  an  operator  is  often 
"called"  by  placing  it  between  or  sometimes  after  the  arguments. 
The  second  difference  is  that  the  compiler  determines  which 
"function"  to  call.  For  instance,  if  you  are  using  the  operator  + with 
fl  oati  ng-poi  nt  argu  ments,  the  compi  I er  "cal  I s"  the  fu  ncti  on  to 
perform  floating-point  addition  (this  "call"  istypically  theactof 
inserting  in-line  code,  or  a floating-point-processor  instruction).  If 
you  use  operator  + with  a floating-point  number  and  an  integer, 
the  compiler  "calls"  a special  function  to  turn  the  int  into  afloat 
and  then  "calls"  the  floating-point  addition  code. 

But  in  C-H-,  it's  possible  to  define  new  operators  that  work  with 
classes.  This  definition  isjustlikean  ordinary  function  definition 
except  that  the  name  of  the  fu  ncti  on  consi  sts  of  the  keyword 
operatorfollowed  by  the  operator.  That's  the  only  difference,  and  it 
becomes  a function  I ike  any  other  function,  which  the  compiler 
calls  when  it  sees  the  appropriate  pattern. 


Warning  & reassurance 

It's  tempting  to  become  overenthusiastic  with  operator 
overloading.  It's  a fun  toy,  at  first.  But  remember  it's  only  syntactic 
sugar,  another  way  of  calling  a function.  Looking  at  it  this  way,  you 
have  no  reason  to  overload  an  operator  except  if  it  wi  1 1 make  the 
cod  e i n vol  V i ng  you  r cl  ass  easi  er  to  w r i te  an  d especi  ally  easi  er  to 
read.  (Remember,  code  is  read  much  more  than  it  is  written.)  If  this 
isn't  the  case,  don't  bother. 

Another  common  response  to  operator  overloading  is  panic; 
suddenly,  C operators  have  no  familiar  meaning  anymore. 
"Everything's  changed  and  all  my  C code  will  do  different  things!" 
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This  isn't  true.  All  the  operators  used  in  expressions  that  contain 
only  built-in  data  types  cannot  be  changed.  You  can  never  overload 
operators  such  that 

1 <<  4; 

behaves  differently,  or 

1.414  <<  2; 

has  meaning.  Only  an  expression  containing  a user-defined  type 
can  have  an  overloaded  operator. 


Syntax 

Defining  an  overloaded  operator  islikedefining  afunction,  but  the 
name  of  that  function  isoperator®  in  which  @ represents  the 
operator  that's  being  overloaded.  The  number  of  arguments  in  the 
overloaded  operator's  argument  list  depends  on  two  factors: 

1.  Whether  it's  a unary  operator  (one argument)  or  a binary 
operator  (two  arguments). 

2.  Whether  the  operator  is  defined  asa  global  function  (one 
argument  for  unary,  two  for  bi  nary)  or  a member  function 
(zero  arguments  for  unary,  one  for  binary  - the  object 
becomes  the  left-hand  argument). 

H ere's  a smal  I class  that  shows  the  syntax  for  operator  overload!  ng: 

/ / : C12 : OperatorOverloadingSyntax . cpp 
#include  <iostream> 
using  namespace  std; 

class  Integer  { 
int  i ; 
public : 

Integer (int  ii)  : i(ii)  {} 
const  Integer 

operator!  (const  Integers  rv)  const  { 
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cout  <<  "operator+"  <<  endl; 
return  Integer (i  + rv.i); 

} 

Integers 

operator+= (const  Integers  rv)  { 
cout  <<  "operator+="  <<  endl; 
i +=  rv.i; 
return  *this; 


}; 


int  main  ( ) { 

cout  <<  "built-in  types:"  <<  endl; 
int  i = 1,  j = 2,  k = 3; 
k +=  i + j; 

cout  <<  "user-defined  types:"  <<  endl; 

Integer  ii(I),  jj(2),  kk(3); 
kk  +=  ii  + j j ; 

} ///:- 

The  two  overloaded  operators  are  defined  as  inline  mennber 
fu  ncti  ons  that  annou  nee  w hen  they  are  cal  I ed . The  si  ngl  e argu  ment 
is  what  appears  on  the  right-hand  side  of  the  operator  for  binary 
operators.  U nary  operators  have  no  arguments  when  defined  as 
member  functions.  The  member  function  iscalled  for  the  object  on 
the  I eft-hand  si  de  of  the  operator. 

For  non-conditional  operators  (conditionals  usually  return  a 
Boolean  value),  you'll  almost  always  want  to  return  an  objector 
reference  of  the  same  type  you're  operati  ng  on  if  the  two 
arguments  are  the  same  type.  (If  they're  not  the  same  type,  the 
interpretation  of  what  it  should  produce  is  up  to  you.)  This  way, 
complicated  expressions  can  be  built  up: 

kk  +=  ii  + jj; 

Theoperator+producesa  new  I nteger(a  temporary)  that  is  used  as 
the  rv  argu  ment  for  the  operator+=  This  temporary  isdestroyed  as 
soon  as  it  is  no  longer  needed. 
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Overloadable  operators 

Although  you  can  overload  almost  all  the  operators  available  in  C, 
the  use  of  operator  overloading  is  fairly  restrictive.  In  particular, 
you  cannot  combi  ne  operators  that  currently  have  no  meaning  in  C 
(such  as**  to  represent  exponentiation),  you  cannot  change  the 
evaluation  precedence  of  operators,  and  you  cannot  change  the 
number  of  arguments  required  by  an  operator.  This  makes  sense - 
all  of  these  actions  would  produce  operators  that  confuse  meaning 
rather  than  clarify  it. 

The  next  two  subsections  give  examples  of  all  the  "regular" 
operators,  overloaded  in  the  form  that  you'll  most  likely  use. 

Unary  operators 

The  foil  owing  example  shows  the  syntax  to  overload  all  the  unary 
operators,  in  theform  of  both  global  functions  (non-member  friend 
functions)  and  as  member  functions.  These  will  expand  upon  the 
Integerclassshown  previously  and  add  a new  byteclass.  The 
meaning  of  your  particular  operators  will  depend  on  the  way  you 
want  to  use  them,  but  consider  the  cl  lent  programmer  before  doing 
something  unexpected. 

Here  is  a catalog  of  all  the  unary  functions: 

/ / : C12 : OverloadingUnaryOperators . cpp 
#include  <iostream> 
using  namespace  std; 

//  Non-member  functions: 
class  Integer  { 
long  i; 

Integer*  This()  { return  this;  } 
public : 

Integer (long  11  = 0)  : 1(11)  {} 

//  No  side  effects  takes  const&  argument: 
friend  const  Integers 

operator!  (const  Integers  a); 
friend  const  Integer 
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operator- (const  Integers  a); 
friend  const  Integer 

operator- (const  Integers  a)  ; 
friend  Integer* 

operators (Integers  a)  ; 
friend  int 

operator! (const  Integers  a); 

//  Side  effects  have  non-constS  argument: 
//  Prefix: 

friend  const  Integers 
operator++ ( Integers  a); 

//  Postfix: 

friend  const  Integer 

operator++ ( Integers  a,  int); 

//  Prefix: 

friend  const  Integers 
operator — (Integers  a); 

//  Postfix: 

friend  const  Integer 

operator — (Integers  a,  int); 

}; 

//  Global  operators: 

const  Integers  operator! (const  Integers  a)  { 
cout  <<  "+Integer\n" ; 
return  a;  //  Unary  + has  no  effect 

} 

const  Integer  operator- (const  Integers  a)  { 
cout  <<  "-IntegerXn" ; 
return  Integer (-a . i)  ; 

} 

const  Integer  operator- (const  Integers  a)  { 
cout  <<  "-IntegerXn" ; 
return  Integer  (-a  . i) ; 

} 

Integer*  operators (Integers  a)  { 
cout  <<  "SIntegerXn"; 
return  a.ThisO;  //  Sa  is  recursive! 

} 

int  operator! (const  Integers  a)  { 
cout  <<  " ! IntegerXn" ; 
return  ! a . i ; 

} 

//  Prefix;  return  incremented  value 
const  Integers  operator!! ( Integers  a)  { 
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cout  <<  "++Integer\n" ; 
a . i++; 
return  a; 

} 

//  Postfix;  return  the  value  before  increment: 
const  Integer  operator++ ( Integers  a,  int)  { 
cout  <<  "Integer++\n" ; 

Integer  before (a. i); 
a . i++; 

return  before; 

} 

//  Prefix;  return  decremented  value 
const  Integers  operator — (Integers  a)  { 
cout  <<  " — IntegerVn"; 
a.  i — ; 
return  a; 

} 

//  Postfix;  return  the  value  before  decrement: 
const  Integer  operator — (Integers  a,  int)  { 
cout  <<  "Integer — \n"; 

Integer  before  (a. i); 
a.  i — ; 

return  before; 

} 

//  Show  that  the  overloaded  operators  work: 
void  f (Integer  a)  { 

+a; 

-a; 

~a; 

Integer*  ip  = Sa; 

! a; 

++a ; 
a++ ; 

— a; 
a — ; 

} 

//  Member  functions  (implicit  "this") : 
class  Byte  { 

unsigned  char  b; 
public : 

Byte (unsigned  char  bb  = 0 ) : b(bb)  {} 

//  No  side  effects:  const  member  function: 
const  Bytes  operator! ()  const  { 
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cout  <<  "+Byte\n"; 
return  *this; 

} 

const  Byte  operator- ()  const  { 
cout  <<  "-Byte\n"; 
return  Byte (-b) ; 


const  Byte  operator- ()  const  { 
cout  <<  "~Byte\n"; 
return  Byte (~b) ; 

} 

Byte  operator! ()  const  { 
cout  <<  "iByteXn"; 
return  Byte (lb); 

} 

Byte*  operators  0 { 

cout  <<  "&Byte\n"; 
return  this; 

} 

//  Side  effects:  non-const  member  function: 
const  Bytes  operator++()  { //  Prefix 
cout  <<  "++Byte\n"; 
b++ ; 

return  *this; 

} 

const  Byte  operator++ ( int ) { //  Postfix 

cout  <<  "Byte++\n"; 

Byte  before (b) ; 
b++ ; 

return  before; 


const  Bytes  operator — ()  { //  Prefix 

cout  <<  " — ByteXn"; 

— b; 

return  *this; 

} 

const  Byte  operator — (int)  { //  Postfix 
cout  <<  "Byte — \n"; 

Byte  before (b) ; 

— b; 

return  before; 


}; 


void  g(Byte  b)  { 
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+b ; 

-b; 

~b; 

Byte*  bp  = &b; 

!b; 

++b } 
b+t ; 

— b; 
b — ; 

} 

int  main  ( ) { 

Integer  a; 
f (a)  ; 

Byte  b; 
g (b)  ; 

} ///:- 

The  fu  ncti  ons  are  grou  ped  accord  i ng  to  the  way  thei  r argu  merits 
are  passed.  Guidelines  for  how  to  pass  and  return  arguments  are 
given  later.  The  forms  above  (and  the  ones  that  follow  in  the  next 
section)  are  typically  what  you'll  use,  so  start  with  them  as  a 
pattern  when  overloading  your  own  operators. 

I ncrement  & decrement 

The  overloaded  ++  and  - - operators  present  a dilemma  because 
you  want  to  beableto  call  different  functions  depending  on 
whether  they  appear  before  (prefix)  or  after  (postfix)  the  object 
they 're  acting  upon.  The  solution  issimple,  but  people  sometimes 
find  it  a bit  confusing  at  first.  When  the  compiler  sees,  for  example, 
++a  (a  pre-increment),  it  generates  a cal  I to  operator++(a)  but 
when  it  sees  a++,  it  generates  a cal  I to  operator++(a,  int)That  is, 
the  compiler  differentiates  between  thetwo  forms  by  making  calls 
to  different  overloaded  functions.  In 
Overload! ngU  naryO  perators.cppor  the  member  function 
versions,  if  the  compiler  sees ++b,  it  generates  a cal  I to 
B::operator++(  }if  it  sees  b++  it  calls  B::operator++(int) 

All  the  user  sees  isthat  a different  function  gets  called  for  the  prefix 
and  postfix  versions.  Underneath,  however,  the  two  functions  cal  Is 
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have  different  signatures,  so  they  i ink  to  two  different  function 
bodies.  Thecompiier  passes  a dummy  constant  vaiuefor  theint 
argument  (which  is  never  given  an  identifier  because  the  vaiue  is 
never  used)  to  generate  the  different  signature  for  the  postfix 
version. 

Binary  operators 

The foii owing  ii sting  repeats  the  exampie  of 

Overload! ngU  naryO  perators.cp^r  bi  nary  operators  so  you  have 
an  exampie  of  aii  the  operators  you  might  want  to  overioad.  Again, 
both  giobai  versions  and  member  function  versions  are  shown. 

//:  C12 : Integer . h 

//  Non-member  overloaded  operators 
#ifndef  INTEGER_H 
#define  INTEGER_H 
#include  <iostream> 

//  Non-member  functions: 
class  Integer  { 
long  i; 
public : 

Integer (long  11  = 0)  : 1(11)  {} 

//  Operators  that  create  new,  modified  value: 
friend  const  Integer 

operator! (const  Integers  left, 

const  Integers  right); 
friend  const  Integer 

operator- (const  Integers  left, 

const  Integers  right); 
friend  const  Integer 

operator* (const  Integers  left, 

const  Integers  right); 
friend  const  Integer 

operator/ (const  Integers  left, 

const  Integers  right); 
friend  const  Integer 

operator%  (const  Integers  left, 

const  Integers  right); 
friend  const  Integer 

operator^  (const  Integers  left. 
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const  Integers  right); 
friend  const  Integer 

operators (const  Integers  left, 

const  Integers  right); 
friend  const  Integer 

operator! (const  Integers  left, 

const  Integers  right); 
friend  const  Integer 

operator<<  (const  Integers  left, 

const  Integers  right); 
friend  const  Integer 

operator>>  (const  Integers  left, 

const  Integers  right); 

//  Assignments  modify  S return  lvalue: 
friend  Integers 

operator+= ( Integers  left, 

const  Integers  right); 
friend  Integers 

operator-= ( Integers  left, 

const  Integers  right); 
friend  Integers 

operator*= ( Integers  left, 

const  Integers  right); 
friend  Integers 

operator/= ( Integers  left, 

const  Integers  right); 
friend  Integers 

operator%= ( Integers  left, 

const  Integers  right); 
friend  Integers 

operator^= ( Integers  left, 

const  Integers  right); 
friend  Integers 

operatorS= ( Integers  left, 

const  Integers  right); 
friend  Integers 

operator  I = ( Integers  left, 

const  Integers  right); 
friend  Integers 

operator>>= ( Integers  left, 

const  Integers  right); 
friend  Integers 

operator<<= ( Integers  left, 

const  Integers  right); 

//  Conditional  operators  return  true/false: 
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friend  int 

operator== (const  Integers  left, 

const  Integers  right); 

friend  int 

operator != (const  Integers  left, 

const  Integers  right); 

friend  int 

operator<  (const  Integers  left, 

const  Integers  right); 

friend  int 

operator>  (const  Integers  left, 

const  Integers  right); 

friend  int 

operator<= (const  Integers  left, 

const  Integers  right); 

friend  int 

operator>= (const  Integers  left, 

const  Integers  right); 

friend  int 

operatorSS  (const  Integers  left, 

const  Integers  right); 

friend  int 

operator!  | (const  Integers  left, 

const  Integers  right); 

//  Write  the  contents  to  an  ostream: 

void  print ( std :: ostreamS  os)  const  { os  <<  i;  } 

}; 

#endif  //  INTEGER_H  ///:- 
//:  C12 : Integer . cpp  {0} 

//  Implementation  of  overloaded  operators 
#include  "Integer. h" 

#include  /require . h" 

const  Integer 

operator!  (const  Integers  left, 

const  Integers  right)  { 
return  Integer ( left . i + right.!); 

} 

const  Integer 

operator- (const  Integers  left, 

const  Integers  right)  { 
return  Integer ( left . i - right.!); 

} 

const  Integer 
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operator* (const  Integers  left, 

const  Integers  right)  { 
return  Integer ( left . i * right.!); 

} 

const  Integer 

operator/  (const  Integers  left, 

const  Integers  right)  { 
require (right . i !=  0,  "divide  by  zero"); 
return  Integer ( left . i / right.!); 

} 

const  Integer 

operator% (const  Integers  left, 

const  Integers  right)  { 
require (right . i !=  0,  "modulo  by  zero"); 
return  Integer ( left . i % right.!); 

} 

const  Integer 

operator^ (const  Integers  left, 

const  Integers  right)  { 
return  Integer ( left . i ^ right.!); 

} 

const  Integer 

operators  (const  Integers  left, 

const  Integers  right)  { 
return  Integer ( left . i S right.!); 

} 

const  Integer 

operator! (const  Integers  left, 

const  Integers  right)  { 
return  Integer ( left . i | right.!); 

} 

const  Integer 

operator<< (const  Integers  left, 

const  Integers  right)  { 
return  Integer ( left . i <<  right.!); 

} 

const  Integer 

operator>> (const  Integers  left, 

const  Integers  right)  { 
return  Integer ( left . i >>  right.!); 

} 

//  Assignments  modify  S return  lvalue: 

Integers  operator+= ( Integers  left, 

const  Integers  right)  { 
if(Sleft  ==  Sright)  {/*  self-assignment  */} 
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left.i  +=  right. i; 
return  left; 

} 

Integers  operator-= ( Integers  left, 

const  Integers  right)  { 
if(Sleft  ==  Sright)  {/*  self-assignment  */} 
left.i  -=  right.!; 
return  left; 

} 

Integers  operator*= ( Integers  left, 

const  Integers  right)  { 
if(Sleft  ==  Sright)  {/*  self-assignment  */} 
left.i  *=  right.!; 
return  left; 

} 

Integers  operator/= ( Integers  left, 

const  Integers  right)  { 
require (right . i !=  0,  "divide  by  zero"); 
if(Sleft  ==  Sright)  {/*  self-assignment  */} 
left.i  /=  right.!; 
return  left; 

} 

Integers  operator%= ( Integers  left, 

const  Integers  right)  { 
require (right . i !=  0,  "modulo  by  zero"); 
if(Sleft  ==  Sright)  {/*  self-assignment  */} 
left.i  %=  right.!; 
return  left; 

} 

Integers  operator^= ( Integers  left, 

const  Integers  right)  { 
if(Sleft  ==  Sright)  {/*  self-assignment  */} 
left.i  right.!; 
return  left; 

} 

Integers  operatorS= ( Integers  left, 

const  Integers  right)  { 
if(Sleft  ==  Sright)  {/*  self-assignment  */} 
left.i  S=  right.!; 
return  left; 

} 

Integers  operator | =( Integers  left, 

const  Integers  right)  { 
if(Sleft  ==  Sright)  {/*  self-assignment  */} 
left.i  1=  right.!; 


524 


Thinking  in  C+  + 


www.BruceEckel.com 


return  left; 

} 

Integers  operator>>= ( Integers  left, 

const  Integers  right)  { 
if(Sleft  ==  Sright)  {/*  self-assignment  */} 
left.i  >>=  right.!; 
return  left; 

} 

Integers  operator<<= ( Integers  left, 

const  Integers  right)  { 
if(Sleft  ==  Sright)  {/*  self-assignment  */} 
left.i  <<=  right.!; 
return  left; 

} 

//  Conditional  operators  return  true/false: 
int  operator== (const  Integers  left, 

const  Integers  right)  { 
return  left.i  ==  right.!; 

} 

int  operator != (const  Integers  left, 

const  Integers  right)  { 
return  left.i  !=  right.!; 

} 

int  operator<  (const  Integers  left, 

const  Integers  right)  { 
return  left.i  < right.!; 

} 

int  operator>  (const  Integers  left, 

const  Integers  right)  { 
return  left.i  > right.!; 

} 

int  operator<= (const  Integers  left, 

const  Integers  right)  { 
return  left.i  <=  right.!; 

} 

int  operator>= (const  Integers  left, 

const  Integers  right)  { 
return  left.i  >=  right.!; 

} 

int  operatorSS  (const  Integers  left, 

const  Integers  right)  { 
return  left.i  SS  right.!; 

} 

int  operator!  | (const  Integers  left, 

const  Integers  right)  { 
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return  left.i  | | right. i; 

} III-.- 

!/:  C12 : IntegerTest . cpp 
//{L}  Integer 
#include  "Integer. h" 

#include  <fstream> 

using  namespace  std; 

of stream  out (" IntegerTest . out " ) ; 

void  h (Integers  cl.  Integers  c2)  { 

//  A complex  expression: 
cl  +=  cl  * c2  + c2  % cl; 

#define  TRY (OP)  \ 

out  <<  "cl  = cl . print  (out ) ; \ 
out  <<  ",  c2  = c2 . print  (out ) ; \ 
out  <<  cl  " #0P  " c2  produces  \ 

(cl  OP  c2 ). print (out ) ; \ 
out  <<  endl; 

TRY(+)  TRY(-)  TRY(*)  TRY(/) 

TRY(%)  TRY(^)  TRY(S)  TRY ( | ) 

TRY(<<)  TRY(>>)  TRY(+=)  TRY(-=) 

TRY(*=)  TRY(/=)  TRY(%=)  TRY(^=) 

TRY(S=)  TRY(|=)  TRY(>>=)  TRY(<<=) 

//  Conditionals: 

#define  TRYC(OP)  \ 

out  <<  "cl  = cl . print (out ) ; \ 
out  <<  ",  c2  = c2 . print  (out ) ; \ 
out  <<  cl  " #0P  " c2  produces  \ 

out  <<  (cl  OP  c2 ) ; \ 

out  <<  endl; 

TRYC(<)  TRYC(>)  TRYC (==)  TRYC(!=)  TRYC (<=) 
TRYC(>=)  TRYC(SS)  TRYC ( | | ) 


int  main  ( ) { 

cout  <<  "friend  functions"  <<  endl; 
Integer  cl (47),  c2(9); 
h (cl,  c2) ; 

} ///:- 

// : C12 : Byte . h 

//  Member  overloaded  operators 
#ifndef  BYTE_H 
#define  BYTE_H 
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#include  /require . h" 

#include  <iostream> 

//  Member  functions  (implicit  "this") : 
class  Byte  { 

unsigned  char  b; 
public : 

Byte (unsigned  char  bb  = 0 ) : b(bb)  {} 

//  No  side  effects:  const  member  function: 
const  Byte 

operatorf  (const  Byte&  right)  const  { 
return  Byte (b  + right. b); 

} 

const  Byte 

operator- (const  Byte&  right)  const  { 
return  Byte (b  - right. b); 

} 

const  Byte 

operator*  (const  Byte&  right)  const  { 
return  Byte (b  * right. b); 

} 

const  Byte 

operator/ (const  Byte&  right)  const  { 
require (right . b !=  0,  "divide  by  zero"); 
return  Byte (b  / right. b); 

} 

const  Byte 

operator%  (const  Byte&  right)  const  { 
require (right . b !=  0,  "modulo  by  zero"); 
return  Byte (b  % right. b); 

} 

const  Byte 

operator^  (const  Byte&  right)  const  { 
return  Byte (b  ^ right. b); 

} 

const  Byte 

operators  (const  Bytes  right)  const  { 
return  Byte (b  S right. b); 

} 

const  Byte 

operator! (const  Bytes  right)  const  { 
return  Byte (b  | right. b); 

} 

const  Byte 

operator<<  (const  Bytes  right)  const  { 
return  Byte (b  <<  right. b); 
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const  Byte 

operator>> (const  Byte&  right)  const  { 
return  Byte (b  >>  right. b); 

} 

//  Assignments  modify  & return  lvalue. 

//  operator=  can  only  be  a member  function: 

Byte&  operator= (const  Byte&  right)  { 

//  Handle  self-assignment: 
if (this  ==  &right)  return  *this; 
b = right . b ; 
return  *this; 

} 

Byte&  operator+= (const  Byte&  right)  { 

if (this  ==  &right)  {/*  self-assignment  */} 
b +=  right . b ; 
return  *this; 

} 

Byte&  operator-= (const  Byte&  right)  { 

if (this  ==  &right)  {/*  self-assignment  */} 
b -=  right . b ; 
return  *this; 

} 

Byte&  operator*= (const  Byte&  right)  { 

if (this  ==  &right)  {/*  self-assignment  */} 
b *=  right . b ; 
return  *this; 

} 

Byte&  operator/= (const  Byte&  right)  { 

require (right . b !=  0,  "divide  by  zero"); 
if (this  ==  &right)  {/*  self-assignment  */} 
b /=  right. b; 
return  *this; 

} 

Byte&  operator%= (const  Byte&  right)  { 

require (right . b !=  0,  "modulo  by  zero"); 
if (this  ==  &right)  {/*  self-assignment  */} 
b %=  right. b; 
return  *this; 

} 

Byte&  operator^= (const  Byte&  right)  { 

if (this  ==  &right)  {/*  self-assignment  */} 
b right . b ; 

return  *this; 
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Byte&  operator&= (const  Byte&  right)  { 

if (this  ==  &right)  {/*  self-assignment  */} 
b &=  right. b; 
return  *this; 

} 

Byte&  operator  I = (const  Byte&  right)  { 

if (this  ==  &right)  {/*  self-assignment  */} 
b 1=  right. b; 
return  *this; 

} 

Byte&  operator>>= (const  Byte&  right)  { 

if (this  ==  &right)  {/*  self-assignment  */} 
b >>=  right . b ; 
return  *this; 

} 

Byte&  operator<<= (const  Byte&  right)  { 

if (this  ==  &right)  {/*  self-assignment  */} 
b <<=  right . b ; 
return  *this; 

} 

//  Conditional  operators  return  true/false: 

int  operator== (const  Byte&  right)  const  { 
return  b ==  right. b; 

} 

int  operator != (const  Byte&  right)  const  { 
return  b !=  right. b; 

} 

int  operator< (const  Byte&  right)  const  { 
return  b < right. b; 

} 

int  operator>  (const  Byte&  right)  const  { 
return  b > right. b; 

} 

int  operator<= (const  Byte&  right)  const  { 
return  b <=  right. b; 

} 

int  operator>= (const  Byte&  right)  const  { 
return  b >=  right. b; 

} 

int  operator&& (const  Byte&  right)  const  { 
return  b &&  right. b; 

} 

int  operator!  | (const  Byte&  right)  const  { 
return  b | | right. b; 

} 


12:  Operator  Overloading 


529 


//  Write  the  contents  to  an  ostream: 
void  print ( std :: ostream&  os)  const  { 
os  <<  "Ox"  <<  std::hex  <<  int  (b)  << 


}; 

#endif  //  BYTE_H  ///:- 

//:  C12 : ByteTest . cpp 
#include  "Byte.h" 

#include  <fstream> 
using  namespace  std; 
ofstream  out ( "ByteTest . out ")  ; 

void  k (Byte&  bl,  Byte&  b2)  { 

bl  = bl  * b2  + b2  % bl; 

#define  TRY2 (OP)  \ 

out  <<  "bl  = ";  bl . print  (out ) ; \ 
out  <<  ",  b2  = ";  b2 . print  (out ) ; \ 
out  <<  ";  bl  " #0P  " b2  produces  " 
(bl  OP  b2 ). print (out ) ; \ 
out  <<  endl; 

bl  = 9;  b2  = 47; 

TRY2(+)  TRY2(-)  TRY2(*)  TRY2(/) 
TRY2(%)  TRY2(^)  TRY2(&)  TRY2 ( | ) 
TRY2(<<)  TRY2(>>)  TRY2 (+=)  TRY2 (-=) 

TRY2(*=)  TRY2(/=)  TRY2 (%=)  TRY2(^=) 
TRY2(&=)  TRY2(|=)  TRY2 (>>=)  TRY2 (<<=) 

TRY2 (=)  //  Assignment  operator 

//  Conditionals: 

#define  TRYC2 (OP)  \ 

out  <<  "bl  = ";  bl . print (out ) ; \ 
out  <<  ",  b2  = ";  b2 . print  (out ) ; \ 
out  <<  ";  bl  " #0P  " b2  produces  " 
out  <<  (bl  OP  b2);  \ 
out  <<  endl; 

bl  = 9;  b2  = 47; 

TRYC2(<)  TRYC2(>)  TRYC2 (==)  TRYC2(!=) 

TRYC2(>=)  TRYC2(&&)  TRYC2 ( | | ) 

//  Chained  assignment: 

Byte  b3  = 92; 


std: : dec; 


\ 


\ 


TRYC2 (<=) 
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bl  = b2  = b3; 


} 

int  main  ( ) { 

out  <<  "member  functions:"  <<  endl; 

Byte  bl (47) , b2 (9) ; 
k(bl,  b2); 

} ///:- 

You  can  seethatoperator=is  only  allowed  to  be  a mennber 
function.  This  is  explained  later. 

N oticethat  al  I of  the  assignment  operators  have  code  to  check  for 
self-assignment;  this  is  a general  guideline.  In  some  cases  this  is  not 
necessary;  for  example,  with  operator+=you  often  want  to  say 
A+=A  and  have  it  add  A to  itself.  The  most  important  pi  ace  to 
check  for  self-assignment  isoperator=becausewith  complicated 
objects  disastrous  results  may  occur.  (In  some  cases  it's  OK,  but  you 
should  always  keep  it  in  mind  when  writing  operator^) 

All  of  the  operators  shown  in  the  previous  two  examples  are 
overloaded  to  hand  lea  single  type.  It's  also  possible  to  overload 
operators  to  handle  mixed  types,  so  you  can  add  apples  to  oranges, 
for  example.  Before  you  start  on  an  exhaustive  overloading  of 
operators,  however,  you  should  look  at  the  section  on  automatic 
type  conversion  later  in  this  chapter.  Often,  a type  conversion  in  the 
right  place  can  save  you  a lot  of  overloaded  operators. 

Arguments  & return  values 

It  may  seem  a little  confusing  at  first  when  you  look  at 
OverloadingUnaryOperators.cp(lnteger.hand  Byte.hand  see  all 

the  different  ways  that  arguments  are  passed  and  returned. 
Although  you  can  pass  and  return  arguments  any  way  you  want  to, 
the  choices  in  these  examples  were  not  selected  at  random.  They 
follow  a logical  pattern,  the  same  one  you'll  wanttousein  most  of 
your  choices. 
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As  with  any  function  argument,  if  you  only  need  to  read 
from  the  argument  and  not  change  it,  defauitto  passing  it  as 
aconstreference.  Ordinary  arithmetic  operations  (like  + and 
-,  etc.)  and  Bool  eans  will  not  change  their  arguments,  so  pass 
by  constreference  is  predominantly  what  you'll  use.  When 
thefunction  is  a class  member,  this  translates  to  making  it  a 
const  member  function.  Only  with  the  operator-assignments 
(like  +=)  and  the  operators  which  change  the  left-hand 
argument,  isthe  left  argument  not  a constant,  but  it's  still 
passed  in  as  an  address  because  it  will  be  changed. 

2.  The  type  of  return  value  you  should  select  depends  on  the 
expected  meaning  of  the  operator.  (Again,  you  can  do 
anything  you  want  with  the  arguments  and  return  values.)  If 
the  effect  of  the  operator  is  to  produce  a new  value,  you  will 
need  to  generate  a new  object  as  the  return  value.  For 
example,  lnteger::operator-lmust  produce  an  I ntegerobject 
that  is  the  sum  of  the  operands.  This  object  is  returned  by 
value  as  a const  so  the  result  cannot  be  modified  as  an 
lvalue. 

3.  All  theassignmentoperatorsmodify  thelvaluaToallowthe 
result  of  the  assignment  to  be  used  in  chained  expressions, 
likea=b=c  it's  expected  that  you  will  return  a reference  to 
that  same  Ivaluethat  was  just  modified.  But  should  this 
reference  bea  constor  nonconsi?  Although  you  read  a=b=c 
from  left  to  right,  the  compiler  parses  it  from  right  to  left,  so 
you're  not  forced  to  return  a nonconstto  support  assignment 
chaining.  However,  people  do  sometimes  expect  to  be  able  to 
perform  an  operation  on  the  thing  that  wasjust  assigned  to, 
such  as  (a=b).func(  )Jto  call  func(  )on  a after  assigning  b to 
it.  Thus,  the  return  valuefor  all  of  the  assignment  operators 
should  bea  nonconstreference to  the  lvalue. 

4.  For  the  logical  operators,  everyone  expects  to  get  at  worst  an 
intback,  and  at  best  a bool.  (Libraries  developed  before  most 
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compilers  supported  C++'s  built-in  bool  will  useintoran 
equivalent  typed ef.) 

The  increment  and  decrement  operators  present  a dilemma  because 
of  thepre-  and  postfix  versions.  Both  versions  change  the  object 
and  so  cannot  treat  the  object  as  a const  The  prefix  version  returns 
the  value  of  the  object  after  it  was  changed,  so  you  expect  to  get 
back  theobjectthat  was  changed.  Thus,  with  prefix  you  can  just 
return  *thisas  a reference.  The  postfix  version  is  supposed  to 
return  the  value  before  the  value  is  changed,  so  you  Ye  forced  to 
create  a separate  object  to  represent  that  value  and  return  it.  So 
with  postfix  you  must  return  by  value  if  you  want  to  preserve  the 
expected  meaning.  (Note that  you'll  someti mes f i nd  the  increment 
and  decrement  operators  returning  an  intor  bool  to  indicate,  for 
example,  whether  an  object  designed  to  move  through  a list  is  at 
the  end  of  that  list.)  Now  the  question  is:  Should  these  be  returned 
asconstor  nonconsP  If  you  allow  the  object  to  be  modified  and 
someone  writes  (++a).func(  )func(  )will  be  operating  on  a itself, 
but  with  (a++).func(  )func(  )operateson  the  temporary  object 
returned  by  the  postfix  operator++ Temporary  objects  are 
automatically  const  so  this  would  be  flagged  by  the  compiler,  but 
for  consistency's  sake  it  may  make  more  sense  to  make  them  both 
const  as  was  done  here.  Or  you  may  choose  to  make  the  prefix 
version  non-constand  the  postfix  const  Because  of  the  variety  of 
meanings  you  may  want  to  give  the  increment  and  decrement 
operators,  they  will  need  to  be  considered  on  a case-by-case  basis. 

Return  by  value  as  const 

Returning  by  valueasaconstcan  seem  a bit  subtle  at  first,  so  it 
deserves  a bit  more  explanation.  Consider  the  binary  operator-i;  If 
you  use  it  in  an  expression  such  asf(a+b]i  the  result  of  a+b 
becomes  a temporary  object  that  is  used  in  the  cal  I tof( ).  Because 
it's  a temporary,  it's  automatically  const  so  whether  you  explicitly 
make  the  return  value  constor  not  has  no  effect. 

However,  it's  also  possible  for  you  to  send  a message  to  the  return 
valueofa+b,  ratherthan  just  passing  it  to  a function.  For  example. 
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you  can  say  (a+b).g( ) in  which  g( ) is  some  member  function  of 
Integer  in  this  case.  By  making  the  return  value  const  you  state 
that  only  a const  member  function  can  be  called  for  that  return 
value.  This  is  const-correct,  because  it  prevents  you  from  storing 
potentially  valuable  information  in  an  object  that  will  mostlikely 
be  lost. 

The  return  optimization 

When  new  objects  are  created  to  return  by  value,  notice  the  form 
used.  I n operator-1;  for  example: 

return  Integer ( left . i + right.!); 

This  may  look  at  first  I ike  a "function  call  to  a constructor,"  but  it's 
not.  The  syntax  is  that  of  a temporary  object;  the  statement  says 
" make  a temporary  I ntegerobject  and  return  it."  Because  of  this, 
you  might  think  that  the  result  is  the  same  as  creating  a named 
local  object  and  returning  that.  However,  it's  quite  different.  If  you 
were  to  say  instead: 

Integer  tmp(left.i  + right.!); 
return  tmp; 

three  things  will  happen.  First,  the  tmp  object  is  created  including 
its  constructor  call . Second,  the  copy-constructor  copies  the  tmp  to 
the  location  of  the  outside  return  value.  Third,  the  destructor  is 
cal  I ed  for  tmp  at  the  end  of  the  scope. 

In  contrast,  the  "returning  a temporary"  approach  works  quite 
differently.  When  thecompiler  sees  you  do  this,  it  knows  that  you 
have  no  other  need  for  the  object  it's  creati  ng  than  to  return  it.  The 
compi  I er  takes  advantage  of  thi s by  bu i I d i ng  the  object  directly  \ nto 
the  location  of  the  outside  return  value.  This  requires  only  a single 
ordinary  constructor  call  (no  copy-constructor  is  necessary)  and 
there's  no  destructor  cal  I because  you  never  actual  ly  create  a local 
object.  Thus,  while  it  doesn't  cost  anything  but  programmer 
awareness,  it's  significantly  more  efficient.  This  is  often  called  the 
retu  rn  val u e optimizati on . 
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Unusual  operators 

Several  additional  operators  have  a slightly  different  syntax  for 
overloading. 

The  subscript,  operator[  ] must  be  a member  function  and  it 
requires  a single  argument.  Because  operator[  Implies  that  the 
object  it's  being  called  for  acts  I ike  an  array,  you  will  often  return  a 
reference  from  this  operator,  so  it  can  be  conveniently  used  on  the 
left-hand  side  of  an  equal  sign.  This  operator  is  commonly 
overloaded;  you 'I  I see  examples  i n the  rest  of  the  book. 

The  operators  new  and  deletecontrol  dynamic  storage  al  location 
and  can  be  overloaded  in  a number  of  different  ways.  Thistopic  is 
covered  in  the  Chapter  13. 

Operator  comma 

The  comma  operator  is  cal  led  when  it  appears  next  to  an  object  of 
the  type  the  comma  is  defined  for.  However,  "operator;'  is  not 
called  for  function  argument  lists,  only  for  objectsthat  areout  in 
the  open,  separated  by  commas.  There  doesn't  seem  to  be  a lot  of 
practical  uses  for  this  operator;  it's  in  the  language  for  consistency. 
Here's  an  example  showing  how  the  comma  function  can  be  cal  led 
when  the  comma  appears  before  an  object,  as  well  as  after: 

/ / : C12 : OverloadingOperatorComma . cpp 
#include  <iostream> 
using  namespace  std; 

class  After  { 
public : 

const  After&  operator, (const  After&)  const  { 
cout  <<  "After :: operator , ()"  <<  endl; 
return  *this; 


}; 


class  Before  { } ; 

Before&  operator,  (int,  Before&  b)  { 
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cout  <<  "Before :: operator , ()"  <<  endl; 
return  b; 

} 

int  main  ( ) { 

After  a,  b; 

a,  b;  //  Operator  comma  called 
Before  c; 

1,  c;  //  Operator  comma  called 
} ///:- 

The  global  function  allows  the  comma  to  be  placed  before  the  object 
in  question.  The  usage  shown  is  fairly  obscure  and  questionable. 
Although  you  would  probably  use  a comma-separated  list  as  part 
of  a more  complex  express!  on,  it'stoosubtletousein  most 
situations. 

Operator- > 

The  operator- >is  generally  used  when  you  want  to  make  an  object 
appear  to  be  a pointer.  Since  such  an  object  has  more  "smarts"  built 
into  it  than  exist  for  atypical  pointer,  an  object  I ike  this  is  often 
called  a smart  po/n ter.  These  are  especially  useful  if  you  want  to 
"wrap"  a class  around  a pointer  to  makethat  pointer  safe,  or  in  the 
common  usage  of  an  iterator,  which  is  an  object  that  moves  through 
a collection  / container  of  other  objects  and  selects  them  one  at  a ti  me, 
without  providing  direct  access  to  the  implementation  of  the 
container.  (You'll  often  find  contai ners  and  iterators  in  class 
libraries,  such  as  in  the  Standard  C-H- Library,  described  in  Volume 
2 of  this  book.) 

A pointer  dereference  operator  must  be  a member  function.  It  has 
additional,  atypical  constraints:  It  must  return  an  object  (or 
reference  to  an  object)  that  also  has  a pointer  dereference  operator, 
or  it  must  return  a pointer  that  can  be  used  to  select  what  the 
poi  nter  dereference  operator  arrow  i s poi  nti  ng  at.  H ere's  a si  mpl e 
example: 

//:  C12 : SmartPolnter . cpp 
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#include  <iostream> 
#include  <vector> 
#include  /require . h" 
using  namespace  std; 

class  Obj  { 

static  int  i,  j; 
public : 


void  f ( ) 

const 

{ cout  << 

i++ 

<<  endl; 

void  g() 

}; 

const 

{ cout  << 

j++ 

<<  endl; 

//  Static 

member 

definitions : 

int  Ob j : : i 

= 47; 

int  Ob j : : j 

II 

//  Container: 
class  ObjContainer  { 
vector<Obj*>  a; 
public : 

void  add(Obj*  obj)  { a . push_back (ob j ) ; } 

friend  class  SmartPointer ; 

}; 


class  SmartPointer  { 

Ob jContainer&  oc; 

int  index; 
public : 

SmartPointer (Ob jContainer&  objc)  : oc(objc)  { 
index  = 0; 

} 

//  Return  value  indicates  end  of  list: 

bool  operator++()  { //  Prefix 

if  (index  >=  oc.a.sizeO)  return  false; 
if (oc . a [f+index]  ==  0)  return  false; 
return  true; 

} 

bool  operator++ ( int ) { //  Postfix 

return  operator++ ( ) ; //  Use  prefix  version 

} 

Obj*  operator->()  const  { 

require (oc . a [ index]  !=  0,  "Zero  value  " 

"returned  by  SmartPointer :: operator->  ()") ; 
return  oc.a[index]; 

} 
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10; 


}; 


int  main  ( ) { 

const  int  sz  = 

Ob  j o [ s z ] ; 

ObjContainer  oc; 
for(int  i = 0;  i < sz;  i++) 
oc . add ( &o [ i ] ) ; //  Fill  it  up 
SmartPointer  sp(oc);  //  Create  an  iterator 
do  { 

sp->f();  //  Pointer  dereference  operator  call 
sp->g ( ) ; 

} while (sp++) ; 

} ///:- 

The  class  Obj  defines  the  objects  that  are  manipulated  in  this 
program.  The  functions  f(  )and  g( ) simply  print  out  interesting 
values  using  staticdata  members.  Pointers  to  these  objects  are 
stored  inside  containers  of  typeObjContaineiusing  itsadd( ) 
function.  ObjContainerlooks  likean  array  of  pointers,  but  you'll 
notice  there's  no  way  to  get  the  pointers  back  out  again.  However, 
SmartPointeiis  declared  as  a friend  class,  so  it  has  permission  to 
look  inside  the  container.  The  SmartPointerd  ass  looks  very  much 
likean  intelligent  pointer -you  can  move  it  forward  using 
operator++(you  can  also  define  an  operator-  it  won't  go  past 

the  end  of  the  container  it's  pointing  to,  and  it  produces  (via  the 
pointer  dereference  operator)  the  value  it's  pointing  to.  Notice  that 
theSmartPointeiis  a custom  fit  for  the  container  it's  created  for; 
unlikean  ordinary  pointer,  there  isn't  a "general  purpose"  smart 
poi  nter.  You  w i 1 1 I earn  more  about  the  smart  poi  nters  cal  I ed 
"iterators"  in  the  last  chapter  of  this  book  and  in  Volume  2 
(down  load  able  from  www.BruceEckel.com). 

In  main( ) once  the  containeroc  isfilled  with  Obj  objects,  a 
S martPoi  nter  spi  s created . The  smart  poi  nter  cal  I s happen  i n the 
expressions: 

sp->f();  //  Smart  pointer  calls 
sp->g ( ) ; 
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Here,  even  though  sp  doesn't  actually  havef(  )and  g( ) member 
functions,  the  pointer  dereference  operator  automatically  calls 
those fu net! ons  for  the Obj* that  is  returned  by 
SmartPointer::operator->The  compiler  performs  all  the  checking 
to  make  sure  the  function  call  works  properly. 

Although  the  underlying  mechanics  of  the  pointer  dereference 
operator  are  more  compi  ex  than  the  other  operators,  the  goal  I s 
exactly  the  same:  to  provide  a more  convenient  syntax  for  the  users 
of  your  classes. 

A nested  iterator 

It's  more  common  to  see  a "smart  pointer"  or  "iterator"  class  nested 
within  the  cl  ass  that  it  services.  The  previous  example  can  be 
rewritten  to  nestSmartPointeiinsideObjContaineiiikethis: 

//:  C12 : NestedSmartPointer . epp 
#include  <iostream> 

#include  <vector> 

#include  ".. /require . h" 
using  namespace  std; 

class  Obj  { 

static  int  i,  j; 
public : 

void  f()  { cout  <<  i++  <<  endl;  } 
void  g()  { cout  <<  j++  <<  endl;  } 

}; 


//  Static  member  definitions: 
int  Ob j : : i = 47 ; 
int  Obj : : j = 11; 

//  Container: 
class  ObjContainer  { 
vector<Obj*>  a; 
public : 

void  add(Obj*  obj)  { a . push_back (ob j ) ; } 

class  SmartPointer ; 
friend  SmartPointer; 
class  SmartPointer  { 
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Ob jContainer&  oc; 

unsigned  int  index; 
public : 

SmartPointer (Ob jContainer&  objc)  : oc(objc)  { 
index  = 0; 

} 

//  Return  value  indicates  end  of  list: 

bool  operator++()  { //  Prefix 

if  (index  >=  oc.a.sizeO)  return  false; 
if (oc . a [++index]  ==  0)  return  false; 
return  true; 

} 

bool  operator++ ( int ) { //  Postfix 

return  operator++ ( ) ; //  Use  prefix  version 

} 

Obj*  operator->()  const  { 

require (oc . a [ index]  !=  0,  "Zero  value  " 

"returned  by  SmartPointer :: operator->  ()") ; 
return  oc.a[index]; 


//  Function  to  produce  a smart  pointer  that 
//  points  to  the  beginning  of  the  Ob jContainer : 
SmartPointer  begin ()  { 

return  SmartPointer ( *this  ) ; 


}; 


int  main  ( ) { 

const  int  sz  = 10; 

Obj  o [ s z ] ; 

ObjContainer  oc; 
for(int  i = 0;  i < sz;  i++) 
oc . add ( &o [ i ] ) ; //  Fill  it  up 
Ob  jContainer  ::  SmartPointer  sp  = oc.beginO; 
do  { 

sp->f();  //  Pointer  dereference  operator  call 
sp->g ( ) ; 

} while (++sp) ; 

} ///:- 

Besides  the  actual  nesting  of  the  cl  ass,  there  are  only  two 
differences  here.  The  first  is  in  the  declaration  of  the  class  so  that  it 
can  be  a friend: 
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class  SmartPointer ; 
friend  SmartPointer; 

The  compi  ler  must  fi  rst  know  that  the  class  exists  before  it  can  be 
told  that  it's  a friend 

The  second  difference  is  in  the ObjContainermember  function 
begin( ) which  produces  a SmartPointerthat  points  to  the 
beginning  of  theObjContaineisequence.  Although  it's  really  only 
a convenience,  it's  valuable  because  it  follows  part  of  the  form  used 
in theStandard  C++Library. 

Operator- >* 

The  operator-  >*is  a bi  nary  operator  that  behaves  I i ke  al  I the  other 
binary  operators.  It  is  provided  for  those  situations  when  you  want 
to  mimic  the  behavior  provided  by  the  built-in  pointer -to- member 
syntax,  described  in  the  previous  chapter. 

J ust  I i ke  operator-::^  the  poi  nter-to-member  dereference  operator  i s 
generally  used  with  some  kind  of  object  that  represents  a "smart 
pointer,"  although  the  example  shown  here  will  besimpler  so  it's 
understandable.  The  trick  when  defining  operator- >*is  that  it  must 
return  an  object  for  which  theoperator(  )can  be  called  with  the 
arguments  for  the  member  functi  on  you're  cal  I i ng. 

The  function  caii  operator! ) must  be  a member  function,  and  it  is 
unique  in  that  it  allows  any  number  of  arguments.  It  makes  your 
object  look  likeit'sactually  afuncti on.  Although  you  could  define 
several  overloaded  operator!  functions  with  different  arguments, 
it'soften  used  for  types  that  only  have  a single  operation,  or  at  least 
an  especially  prominent  one.  You'll  see  in  Volume  2 that  the 
Standard  C-h- Library  uses  the  functi  on  call  operator  in  order  to 
create  "functi on  objects." 

To  create  an  operator- >*you  must  first  create  a class  with  an 
operator!  )that  is  the  type  of  object  that  operator- >*wi  1 1 return. 
This  class  must  somehow  capture  the  necessary  information  so  that 
when  the  operator!  )is  called  (which  happens  automatically),  the 
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pointer-to-member  will  be  dereferenced  for  the  object.  In  the 
following  example,  the  FunctionObjectonstructor  captures  and 
stores  both  the  poi  nter  to  the  object  and  the  poi  nter  to  the  member 
function,  and  then  theoperator(  )uses  those  to  make  the  actual 
poi  nter-to-member  cal  I : 

/ / : C12 : PointerToMemberOperator . cpp 
#include  <iostream> 
using  namespace  std; 

class  Dog  { 
public : 

int  run(int  1)  const  { 
cout  <<  "run\n"; 
return  1; 

} 

int  eat  (int  i)  const  { 
cout  <<  "eat\n"; 
return  i; 

} 

int  sleep  (int  i)  const  { 
cout  <<  "ZZZ\n"; 
return  i; 

} 

typedef  int  (Dog::*PMF)  (int)  const; 

//  operator->*  must  return  an  object 
//  that  has  an  operator () : 
class  FunctionOb ject  { 

Dog*  ptr; 

PMF  pmem; 
public : 

//  Save  the  object  pointer  and  member  pointer 
FunctionOb ject (Dog*  wp,  PMF  pmf ) 

: ptr(wp),  pmem (pmf)  { 

cout  <<  "FunctionOb ject  constructor\n" ; 

} 

//  Make  the  call  using  the  object  pointer 

//  and  member  pointer 

int  operator  0 (int  i)  const  { 

cout  <<  "FunctionOb ject :: operator  0 \n" ; 
return  (ptr->*pmem) (i);  //  Make  the  call 


}; 
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FunctionOb ject  operator->* (PMF  pmf ) { 

cout  <<  "operator->* " <<  endl; 
return  FunctionOb ject (this,  pmf); 


}; 


int  main  ( ) { 

Dog  w ; 

Dog::PMF  pmf  = &Dog::run; 

cout  <<  (w->*pmf) (1)  <<  endl; 

pmf  = &Dog::sleep; 

cout  <<  (w->*pmf) (2)  <<  endl; 

pmf  = &Dog : : eat ; 

cout  <<  (w->*pmf) (3)  <<  endl; 

} ///:- 

Dog  has  three  member  functions,  all  of  which  take  an  int  argument 
and  return  an  int  PM  F isatypedefto  simplify  defining  a pointer- 
to-memberto  Dog's  member  functions. 

A FunctionObjectts created  and  returned  by  operator- >*  Notice 
that  operator- >*knows  both  the  object  that  the  poi  nter-to-member 
is  being  called  for  (this)  and  the  poi  nter-to-member,  and  it  passes 
those  to  the  FunctionObjectonstructor  that  stores  the  values. 
When  operator- >*is  called,  the  compiler  immediately  turns  around 
and  cal  Is  operator(  )for  the  return  value  of  operator->*  passing  in 
the  arguments  that  were  given  to  operator- >*  The 
FunctionO  bject::operator(t^kes  the  arguments  and  then 
dereferences  the  "real"  poi  nter-to-member  using  its  stored  object 
pointer  and  poi  nter-to-member. 

Notice  that  what  you  are  doing  here,  just  as  with  operator- ::>  is 
i nserti  ng  you rself  i n the  mi dd I e of  the  cal  I to  operator- >* This 
al  I ows  you  to  perform  some  extra  operati  ons  if  you  need  to. 

The  operator- >*mechanism  implemented  here  only  works  for 
member  functions  that  take  an  int  argument  and  return  an  int  This 
is  limiting,  but  if  you  try  to  create  overloaded  mechanisms  for  each 
different  possibility,  it  seems  I ike  a prohibitive  task.  Fortunately, 
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C++'stemplatemechanisnn  (described  in  the  last  chapter  of  this 
book,  and  in  Volume  2)  is  designed  to  handlejustsuch  a problem. 

Operators  you  can't  overload 

There  are  certai  n operators  in  the  aval  I able  set  that  cannot  be 
overloaded.  The  general  reason  for  the  restriction  issafety.  If  these 
operators  were  overload  able,  it  would  somehow  jeopardize  or 
break  safety  mechanisms,  make  things  harder,  or  confuse  existing 
practice. 

• The  member  selection  operator.  Currently,  the  dot  has  a 
meaning  for  any  member  in  a cl  ass,  but  if  you  allow  it  to  be 
overloaded,  then  you  couldn't  access  members  in  the  normal 
way;  instead  you'd  have  to  use  a pointer  and  the  arrow 

operator- > 

• The  poi  nter  to  member  dereference  operator.*  for  the  same 
reason  as  operator. 

• There's  no  exponent!  ati  on  operator.  The  most  popu  I ar  choi  ce 
for  this  was  operator**from  Fortran,  but  this  raised  difficult 
parsing  questions.  Also,  C has  no  exponentiation  operator,  so 
C++didn'tseemto  need  one  either  because  you  can  always 
perform  a function  call.  An  exponentiation  operator  would  add 
a convenient  notation,  but  no  new  language  functionality  to 
account  for  the  added  complexity  of  the  compiler. 

• There  are  no  user-defined  operators.  That  is,  you  can't  make  up 
new  operators  that  aren't  currently  in  the  set.  Part  of  the 
problem  is  how  to  determine  precedence,  and  part  of  the 
problem  is  an  insufficient  need  to  account  for  the  necessary 
trouble. 

• You  can't  change  the  precedence  rules.  They're  hard  enough  to 

remember  as  it  is  without  letting  people  play  with  them. 
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Non-member  operators 

In  some  of  the  previous  examples,  theoperators  may  be  members 
or  non-members,  and  it  doesn't  seem  to  make  much  difference. 
Thisusually  raises  the  question,  "Which  should  I choose?"  In 
general,  if  it  doesn't  makeany  difference,  they  should  be  members, 
to  emphasize  the  association  between  the  operator  and  its  class. 
When  the  left-hand  operand  is  always  an  object  of  the  current  class, 
this  works  fine. 

H owever,  someti  mes  you  want  the  left-hand  operand  to  be  an 
objectof  some  other  class.  A common  place  you'll  see  this  is  when 
the  operators  « and  » are  overloaded  for  iostreams.  Si  nee 
iostreams  is  a fundamental  C-h- library,  you'll  probably  want  to 
overl  oad  these  operators  for  most  of  you  r cl  asses,  so  the  process  i s 
worth  memorizing: 

// : C12 : lostreamOperatorOverloading . epp 
//  Example  of  non-member  overloaded  operators 
#include  ".. /require . h" 

#include  <iostream> 

#include  <sstream>  //  "String  streams" 

#include  <cstring> 
using  namespace  std; 

class  IntArray  { 
enum  { sz  = 5 } ; 
int  i [ sz ] ; 
public : 

IntArray 0 { memset(i,  0,  sz*  sizeof(*i));  } 

int&  operator [] (int  x)  { 
require (x  >=  0 &&  x < sz, 

" IntArray :: operator [ ] out  of  range"); 
return  i [x] ; 

} 

friend  ostream& 

operator<< (ostream&  os,  const  IntArray&  ia) ; 
friend  istream& 

operator>> ( istream&  is,  IntArray&  ia)  ; 

}; 
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ostream& 

operator<< (ostream&  os,  const  IntArray&  ia)  { 
for(int  j = 0;  j < ia.sz;  j++)  { 

os  <<  ia . i [ j ] ; 
if ( j ! = ia.sz  -1 ) 
os  <<  ", 

} 

os  <<  endl; 
return  os; 


istream&  operator>> ( istream&  is,  IntArray&  ia) { 
for(int  j = 0;  j < ia.sz;  jt+) 
is  >>  ia . i [ j ] ; 
return  is; 

} 

int  main  ( ) { 

stringstream  input ("47  34  56  92  103"); 

IntArray  I; 
input  >>  I; 

I [4]  = -1;  //  Use  overloaded  operator [] 
cout  <<  I; 

} ///:- 

This  class  also  contains  an  overloaded  operator  [ ] which  returns  a 
reference  to  a I egiti  mate  val  ue  i n the  array.  Because  a reference  i s 
returned,  the  expression 

I[4]  = -1; 

not  only  looks  much  more  civilized  than  if  pointers  were  used,  it 
also  accomplishes  the  desired  effect. 

It's  i mportant  that  the  overloaded  shift  operators  pass  and  return 
by  reference,  so  the  actions  wi  1 1 affect  the  external  objects.  I n the 
function  definitions,  expressions  like 

os  <<  ia . i [ j ] ; 

causetheex^/st/ngoverloaded  operator  functions  to  be  cal  led  (that 
is,  those  defined  in  <iostream?).  In  thiscase,  thefunction  called  is 
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ostream&  operator«(ostream&,  int^duseia.i[j]  resolves  to  an 
int 

Once  all  the  actions  are  performed  on  the  i stream  or  ostream  it  is 
returned  so  it  can  be  used  in  a more  complicated  expression. 

In  main( ) a new  typeofi  ostream  is  used:  thestringstream 

(declared  in  <sstream?).  This  is  a class  that  takes  a string(which  it 
can  create  from  a char  array,  as  shown  here)  and  turns  it  into  an 
iostream  I n the  example  above,  this  means  that  the  shift  operators 
can  be  tested  without  opening  a file  or  typing  data  in  on  the 
command  line. 

The  form  shown  in  this  example  for  the  inserter  and  extractor  is 
standard.  If  you  want  to  create  these  operators  for  your  own  class, 
copy  the  function  signatures  and  return  types  above  and  follow  the 
form  of  the  body. 

Basic  guidelines 

Murray!  suggests  these  guidelines  for  choosing  between  members 
and  non-members: 


Operator 

Recommended  use 

All  unary  operators 

member 

= ()[]->->* 

must  be  member 

+=  -=  /=  *=  -= 

&=  1 = %=  »=  «= 

member 

All  other  binary 
operators 

non-member 

! Rob  M urray,  C ++  Strategies  & T actics,  Addison-Wesley,  1993,  page  47. 
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Overloading  assignment 

A common  source  of  confusion  with  new  C++ programmers  is 
assignment.  This  is  no  doubt  becausethe  = sign  is  such  a 
fundamental  operation  in  programming,  right  down  to  copying  a 
register  at  the  machine  level.  In  addition,  the  copy-constructor 
(described  in  Chapter  11)  is  also  sometimes  invoked  when  the  = 
sign  is  used: 

MyType  b; 

MyType  a = b; 
a = b; 

In  the  second  line,  theobject  a is  being  defined.  A new  object  is 
being  created  where  one  didn't  exist  before.  Because  you  know  by 
now  how  defensivetheC-H- compiler  is  about  object  initialization, 
you  know  that  a constructor  must  always  be  cal  led  at  the  point 
where  an  object  is  defined.  But  which  constructor?  a is  being 
created  from  an  existing  MyTypeobject  (b,  on  the  right  sideof  the 
equal  sign),  so  there's  only  one  choice:  the  copy-constructor.  Even 
though  an  equal  sign  is  involved,  the  copy-constructor  is  cal  led. 

I n the  thi  rd  I i ne,  thi ngs  are  d ifferent.  On  the  left  side  of  the  equal 
sign,  there's  a previously  initialized  object.  Clearly,  you  don't  call  a 
constructor  for  an  object  that's  al  ready  been  created.  I n this  case 
M yType::operatoNs  called  for  a,  taking  as  an  argument  whatever 
appears  on  the  right-hand  side.  (You  can  have  multi  pie  operators 
functions  to  take  different  types  of  right-hand  arguments.) 

This  behavior  is  not  restricted  to  the  copy-constructor.  Any  time 
you're  initializing  an  object  using  an  = instead  of  the  ordinary 
function-call  form  of  the  constructor,  the  compiler  will  look  for  a 
constructor  that  accepts  whatever  is  on  the  right-hand  side: 

// : C12 : CopyingVsInitialization . cpp 
class  Fi  { 
public : 

Fi()  {} 

}; 
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class  Fee  { 
public : 

Fee ( int ) { } 

Fee (const  F1& ) { } 


int  main  ( ) { 

Fee  fee  = 1;  //  Fee  (int) 

Fi  fi; 

Fee  fum  = fi;  //  Fee(Fi) 

} ///:- 

When  dealing  with  the  = sign,  it's  important  to  keep  this  distinction 
in  mind:  If  the  object  hasn't  been  created  yet,  initialization  is 
requ  i red ; otherw  i se  the  assi  gn  ment  operator=i  s used . 

It's  even  better  to  avoid  writing  code  that  uses  the  = for 
initialization;  instead,  always  usethe  explicit  constructor  form.  The 
two  constructions  with  the  equal  sign  then  become: 

Fee  fee  ( 1 ) ; 

Fee  fum (f i) ; 

This  way,  you'll  avoid  confusing  your  readers. 

Behavior  of  operator= 

I n I nteger.hand  Byte.h,  you  saw  that  operator=can  be  only  a 
member  function.  It  is  intimately  connected  to  theobject  on  the  left 
sideof  the'- . If  it  was  possibleto  defineoperator=globally,  then 
you  might  attempt  to  redefinethe  built-in  '='  sign: 

I int  operator= ( int , MyType);  //  Global  = not  allowed! 

The  compiler  skirtsthis  whole  issue  by  forcing  you  to  make 
operator=a  member  function. 

When  you  create  an  operator^  you  must  copy  al  I of  the  necessary 
information  from  the  right-hand  object  into  the  current  object  (that 
is,  the  object  that  operator=is  being  cal  led  for)  to  perform  whatever 
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you  consider  "assignment"  for  your  class.  For  simple  objects,  this  is 
obvious: 


//:  C12 : SimpleAssignment . cpp 
//  Simple  operator=() 

#include  <iostream> 
using  namespace  std; 

class  Value  { 
int  a,  b; 
float  c; 
public : 

Value  (int  aa  = 0,  int  bb  = 0,  float  cc  = 0.0) 
: a(aa),  b(bb),  c(cc)  {} 

Values  operator=  (const  Values  rv)  { 
a = rv.a; 
b = rv.b; 
c = rv . c; 
return  *this; 

} 

friend  ostreamS 

operator<< (ostreamS  os,  const  Values  rv)  { 
return  os  <<  "a  = " <<  rv.a  <<  ",  b = " 

<<  rv.b  <<  ",  c = " <<  rv.c; 


}; 


int  main  ( ) { 

Value  a,  b(l,  2,  3.3); 
cout  <<  "a:  " <<  a <<  endl; 
cout  <<  "b:  " <<  b <<  endl; 
a = b; 

cout  <<  "a  after  assignment:  " <<  a <<  endl; 

} ///:- 

H ere,  the  object  on  the  I eft  si  de  of  the  = copi  es  al  I the  el  ements  of 
the  object  on  the  right,  then  returns  a reference  to  itself,  which 
al  I ows  a more  compi  ex  express!  on  to  be  created . 

This  example  includes  a common  mistake.  When  you're  assigning 
two  objects  of  the  same  type,  you  should  always  check  first  for  self- 
assignment: is  the  object  being  assigned  to  itself?  In  some  cases, 
such  as  this  one,  it's  harmless  if  you  perform  the  assignment 
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operations  anyway,  but  if  changes  are  madeto  the  implementation 
of  the  class,  it  can  make  a difference,  and  if  you  don't  do  it  as  a 
matter  of  habit,  you  may  forget  and  cause  hard-to-fi  nd  bugs. 

Pointers  in  ciasses 

What  happens  if  the  object  is  not  so  simple?  For  example,  what  if 
the  object  contai  ns  poi  nters  to  other  objects?  Si  mply  copyi  ng  a 
pointer  means  that  you'll  end  up  with  two  objects  pointing  to  the 
same  storage  location.  In  situations  I ike  these,  you  need  to  do 
bookkeeping  of  your  own. 

There  are  two  common  approaches  to  this  problem.  The  simplest 
technique  is  to  copy  whatever  the  poi  nter  refers  to  when  you  do  an 
assignment  or  a copy-construction.  This  is  straightforward: 

//:  C12 : CopyingWithPointers . cpp 
//  Solving  the  pointer  aliasing  problem  by 
//  duplicating  what  is  pointed  to  during 
//  assignment  and  copy-construction. 

#include  ".. /require . h" 

#include  <string> 

#include  <iostream> 
using  namespace  std; 

class  Dog  { 
string  nm; 
public : 

Dog (const  strings  name)  : nm(name)  { 

cout  <<  "Creating  Dog:  " <<  *this  <<  endl; 

} 

//  Synthesized  copy-constructor  & operator= 

//  are  correct. 

//  Create  a Dog  from  a Dog  pointer: 

Dog (const  Dog*  dp,  const  strings  msg) 

: nm(dp->nm  + msg)  { 

cout  <<  "Copied  dog  " <<  *this  <<  " from  " 

<<  *dp  <<  endl; 


~Dog()  { 

cout  <<  "Deleting  Dog:  " <<  *this  <<  endl; 

} 

void  rename (const  strings  newName)  { 
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nm 


= newName; 

cout  <<  "Dog  renamed  to:  " <<  *this  <<  endl; 

} 

friend  ostream& 

operator<< (ostream&  os,  const  Dog&  d)  { 
return  os  <<  "["  <<  d.nm  << 


}; 


class  DogHouse  { 

Dog*  p; 

string  houseName; 
public : 

DogHouse (Dog*  dog,  const  strings  house) 

: p (dog) , houseName (house ) {} 

DogHouse (const  DogHouseS  dh) 

: p (new  Dog(dh.p,  " copy-constructed")), 
houseName (dh . houseName 

+ " copy-constructed")  {} 

DogHouseS  operator= (const  DogHouseS  dh)  { 

//  Check  for  self-assignment: 
if ( &dh  ! = this ) { 

p = new  Dog(dh.p,  " assigned"); 
houseName  = dh. houseName  + " assigned"; 

} 

return  *this; 

} 

void  renameHouse (const  strings  newName)  { 
houseName  = newName; 

} 

Dog*  getDogO  const  { return  p;  } 

-DogHouse 0 { delete  p;  } 

friend  ostreamS 

operator<< (ostreamS  os,  const  DogHouseS  dh)  { 
return  os  <<  "["  <<  dh. houseName 
<<  "]  contains  " <<  *dh.p; 


}; 


int  main  ( ) { 

DogHouse  fidos  (new  DogC'Fido"),  "FidoHouse " ) ; 
cout  <<  fidos  <<  endl; 

DogHouse  fidos2  = fidos;  //  Copy  construction 

cout  <<  fidos2  <<  endl; 

fidos 2 . get Dog ( ) -> rename ( "Spot " ) ; 
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f idos2 . renameHouse ( "SpotHouse" ) ; 

cout  <<  fidos2  <<  endl; 

fidos  = fidos2;  //  Assignment 

cout  <<  fidos  <<  endl; 

fidos . getDog ( ) ->rename ( "Max" ) ; 

f idos2 . renameHouse ( "MaxHouse" ) ; 

} ///:- 

D og  i s a si  mpl  e cl  ass  that  contai  ns  only  a stri  ngthat  hoi  ds  the 
name  of  the  dog.  However,  you'll  generally  know  when  something 
happens  to  a D og  because  the  constructors  and  destructors  pri  nt 
I nformati  on  w hen  they  are  cal  I ed . N oti  ce  that  the  second 
constructor  is  a bit  1 1 ke  a copy-constructor  except  that  it  takes  a 
poi  nter  to  a D og  i nstead  of  a reference,  and  it  has  a second 
argument  that  is  a message  that's  concatenated  to  the  argument 
Dog's  name.  This  is  used  to  help  trace  the  behavior  of  the  program. 

You  can  seethatwhenever  a member  function  prints  information,  it 
doesn't  access  that  information  directly  but  instead  sends*thisto 
cout  This  in  turn  callstheostreamoperator«  It's  valuable  to  do  it 
this  way  because  if  you  want  to  reformattheway  that  Dog 
information  is  displayed  (as  I did  by  adding  the'['  and  ']')  you  only 
need  to  do  it  in  one  place. 

A DogHousecontainsa  Dog*and  demonstrates  the  four  functions 
you  will  always  need  to  define  when  your  cl  ass  contai  ns  pointers: 
al I necessary  ordinary  constructors,  the  copy-constructor, 
operator=(either  define  it  or  disallow  it),  and  a destructor.  The 
operator=checks for  self-assignment  as  a matter  of  course,  even 
though  it's  not  strictly  necessary  here.  This  virtually  el  i mi  nates  the 
possibility  that  you'll  forget  to  checkfor  self-assignment  if  you  do 
change  the  code  so  that  it  matters. 

Reference  Counting 

In  the  example  above,  the  copy-constructor  and  operator=make  a 
new  copy  of  what  the  poi  nter  points  to,  and  the  destructor  deletes 
it.  However,  if  your  object  requires  a lot  of  memory  or  a high 
initialization  overhead,  you  may  want  to  avoid  this  copying.  A 
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common  approach  to  this  problem  is  cal  led  reference  counting.  You 
give  intelligence  to  the  object  that's  being  pointed  to  so  it  knows 
how  many  objects  are  pointing  to  it.  Then  copy-construction  or 
assignment  means  attaching  another  pointer  to  an  existing  object 
and  incrementing  the  reference  count.  Destruction  means  reducing 
the  reference  count  and  destroying  the  object  if  the  reference  count 
goes  to  zero. 

But  what  if  you  want  to  write  to  the  object  (the  Dog  in  the  example 
above)?  More  than  one  object  may  be  using  this  Dog,  so  you'd  be 
modifying  someone  el  se's  Dog  as  well  as  yours,  which  doesn't 
seem  very  neighborly.  To  solve  this  "aliasing"  problem,  an 
additional  technique  cal  led  copy-on-i/i/r/'teisused.  Before  writing  to  a 
block  of  memory,  you  makesureno  one  else  is  using  it.  Ifthe 
reference  count  is  greater  than  one,  you  must  make  yourself  a 
personal  copy  of  that  block  before  writing  it,  so  you  don't  disturb 
someone  el  se's  turf.  H ere's  a simple  example  of  reference  counting 
and  copy-on-write: 

//:  C12 : Referencecounting . cpp 
//  Reference  count,  copy-on-write 
#inciude  ".. /require . h" 

#inciude  <string> 

#inciude  <iostream> 
using  namespace  std; 

ciass  Dog  { 
string  nm; 
int  ref count; 

Dog (const  strings  name) 

: nm(name),  refcount(i)  { 

cout  <<  "Creating  Dog:  " <<  *this  <<  endi; 

} 

//  Prevent  assignment: 

Dogs  operator= (const  Dog&  rv)  ; 
pubiic : 

//  Dogs  can  oniy  be  created  on  the  heap: 
static  Dog*  make (const  strings  name)  { 
return  new  Dog (name); 

} 
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Dog (const  Dog&  d) 

: nm(d.nin  + " copy")?  refcount(l)  { 
cout  <<  "Dog  copy-constructor:  " 

<<  *this  <<  endl; 

} 

~Dog()  { 

cout  <<  "Deleting  Dog:  " <<  *this  <<  endl; 

} 

void  attach  0 { 

++ref count ; 

cout  <<  "Attached  Dog:  " <<  *this  <<  endl; 

} 

void  detach  0 { 

require (refcount  !=  0); 

cout  <<  "Detaching  Dog:  " <<  *this  <<  endl; 
//  Destroy  object  if  no  one  is  using  it: 
if  ( — refcount  ==  0)  delete  this; 

} 

//  Conditionally  copy  this  Dog. 

//  Call  before  modifying  the  Dog,  assign 
//  resulting  pointer  to  your  Dog*. 

Dog*  unalias ( ) { 

cout  <<  "Unaliasing  Dog:  " <<  *this  <<  endl; 
//  Don't  duplicate  if  not  aliased: 
if (refcount  ==  1)  return  this; 

— refcount ; 

//  Use  copy-constructor  to  duplicate: 
return  new  Dog(*this); 

} 

void  rename (const  strings  newName)  { 
nm  = newName; 

cout  <<  "Dog  renamed  to:  " <<  *this  <<  endl; 

} 

friend  ostreamS 

operator<< (ostreamS  os,  const  Dog&  d)  { 
return  os  <<  "["  <<  d.nm  <<  "],  rc  = " 

<<  d. refcount; 


}; 


class  Doghouse  { 

Dog*  p; 

string  houseName; 
public : 

Doghouse (Dog*  dog,  const  strings  house) 
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: p (dog) , houseName (house ) { 

cout  <<  "Created  Doghouse:  "<<  *this  <<  endl; 

} 

Doghouse (const  Doghouses  dh) 

: p(dh.p), 

houseName ( "copy-constructed  " + 
dh . houseName ) { 

p->attach ( ) ; 

cout  <<  "Doghouse  copy-constructor:  " 

<<  *this  <<  endl; 

} 

Doghouses  operator=  (const  Doghouses  dh)  { 

//  Check  for  self-assignment: 
if ( Sdh  ! = this ) { 

houseName  = dh. houseName  + " assigned"; 

//  Clean  up  what  you're  using  first: 
p->detach ( ) ; 

p = dh.p;  //  Like  copy-constructor 
p->attach ( ) ; 

} 

cout  <<  "Doghouse  operator=  : " 

<<  *this  <<  endl; 
return  *this; 

} 

//  Decrement  refcount,  conditionally  destroy 
-Doghouse ( ) { 

cout  <<  "Doghouse  destructor:  " 

<<  *this  <<  endl; 
p->detach ( ) ; 

} 

void  renamehouse (const  strings  newName)  { 
houseName  = newName; 

} 

void  unalias  0 { p = p->unalias  ( ) ; } 

//  Copy-on-write.  Anytime  you  modify  the 
//  contents  of  the  pointer  you  must 
//  first  unalias  it: 

void  renameDog (const  strings  newName)  { 
unalias  ( ) ; 
p->rename (newName)  ; 

} 

//  ...  or  when  you  allow  someone  else  access: 
Dog*  getDogO  { 
unalias  ( ) ; 
return  p; 
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} 

friend  ostream& 

operator<< (ostream&  os,  const  DogHouse&  dh)  { 
return  os  <<  "["  <<  dh . houseName 
<<  "]  contains  " <<  *dh.p; 


}; 


int  main  ( ) { 

Doghouse 

fidos (Dog: :make ("Fido") , "FidoHouse") , 
spots (Dog: :make ("Spot") , "SpotHouse") ; 
cout  <<  "Entering  copy-construction"  <<  endl; 

Doghouse  bobs (fidos); 

cout  <<  "After  copy-constructing  bobs"  <<  endl; 

cout  <<  "fidos:"  <<  fidos  <<  endl; 

cout  <<  "spots:"  <<  spots  <<  endl; 

cout  <<  "bobs:"  <<  bobs  <<  endl; 

cout  <<  "Entering  spots  = fidos"  <<  endl; 

spots  = fidos; 

cout  <<  "After  spots  = fidos"  <<  endl; 
cout  <<  "spots:"  <<  spots  <<  endl; 
cout  <<  "Entering  self-assignment"  <<  endl; 
bobs  = bobs; 

cout  <<  "After  self-assignment"  <<  endl; 
cout  <<  "bobs:"  <<  bobs  <<  endl; 

//  Comment  out  the  following  lines: 

cout  <<  "Entering  rename ( \ "Bob\ ") " <<  endl; 

bobs . getDog ( ) ->rename ( "Bob" ) ; 

cout  <<  "After  rename ( \ "Bob\ ") " <<  endl; 

} ///:- 

The  cl  ass  D og  i s the  object  poi  nted  to  by  a D ogH  ouse  1 1 contai  ns  a 
reference  count  and  functions  to  control  and  read  the  reference 
count.  There's  a copy-constructor  so  you  can  make  a new  D og  from 
an  existing  one. 

The  attache  )function  incrementsthereferencecountof  aDogto 
indicatethere's  another  object  using  it.  detach(  )decrementsthe 
reference  cou  nt.  I f the  reference  cou  nt  goes  to  zero,  then  no  one  i s 
using  it  anymore,  so  the  member  function  destroys  its  own  object 
by  saying  delete  this 
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Before  you  makeany  modifications  (such  as  renaming  a Dog),  you 
should  ensure  that  you  aren't  changing  a Dog  that  some  other 
object  is  using.  You  do  this  by  calling  DogHouse::unalias(,)which 
in  turn  calls  Dog::unalias(  )The  I after  function  will  return  the 
existing  Dog  pointer  if  the  reference  count  is  one  (meaning  no  one 
el  se  i s poi  nti  ng  to  that  D og),  but  w i 1 1 d u pi  i cate  the  D og  i f the 
reference  count  is  more  than  one. 

The  copy-constructor,  instead  of  creating  its  own  memory,  assigns 
Dog  to  the  Dog  of  the  source  object.  Then,  because  there's  now  an 
additional  object  using  that  block  of  memory,  it  i ncrements  the 
reference  count  by  cal  I i ng  D og::attach( ) 

The operator=deals  with  an  object  that  has  already  been  created  on 
the  left  side  of  the  =,  so  it  must  first  clean  that  up  by  calling 
detach(  )for  that  Dog,  which  will  destroy  the  old  Dog  if  no  one  else 
is  using  it.  Then  operator=repeatsthebehavior  of  the  copy- 
constructor.  N oticethat  it  first  checks  to  detect  whether  you're 
assigning  the  same  object  to  itself. 

The  destructor  callsdetach(  )to  conditionally  destroy  the  Dog. 

To  implement  copy-on-write,  you  must  control  all  the  actions  that 
write  to  your  block  of  memory.  For  example,  therenameDog( ) 
member  fu  ncti  on  al  I ows  you  to  change  the  val  ues  i n the  bl  ock  of 
memory.  But  first,  it  usesunalias(  Ko  prevent  the  modification  of 
an  aliased  Dog(aDogwith  more  than  oneDogHouseobject 
poi  nti  ng  to  it).  A nd  if  you  need  to  produce  a poi  nter  to  a D og  from 
within  a Doghouse  you  unalias(  ythat  pointer  first. 

main(  )tests  the  various  functions  that  must  work  correctly  to 
implement  reference  counting:  the  constructor,  copy-constructor, 
operator^  and  destructor.  It  also  tests  the  copy-on-write  by  calling 

renameDog( ) 

H ere's  the  output  (after  a I ifti  e reformafti  ng) : 
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Creating  Dog:  [Fido] , rc  = 1 

Created  DogHouse:  [FidoHouse] 

contains  [Fido] , rc  = 1 
Creating  Dog:  [Spot],  rc  = 1 

Created  DogHouse:  [SpotHouse] 

contains  [Spot],  rc  = 1 
Entering  copy-construction 
Attached  Dog:  [Fido],  rc  = 2 

DogHouse  copy-constructor: 

[copy-constructed  FidoHouse] 
contains  [Fido] , rc  = 2 
After  copy-constructing  bobs 
fidos: [FidoHouse]  contains  [Fido],  rc  = 2 
spots : [SpotHouse]  contains  [Spot],  rc  = 1 
bobs: [copy-constructed  FidoHouse] 
contains  [Fido] , rc  = 2 
Entering  spots  = fidos 
Detaching  Dog:  [Spot],  rc  = 1 

Deleting  Dog:  [Spot],  rc  = 0 

Attached  Dog:  [Fido],  rc  = 3 

DogHouse  operator=  : [FidoHouse  assigned] 

contains  [Fido] , rc  = 3 
After  spots  = fidos 

spots : [FidoHouse  assigned]  contains  [Fido],rc  = 3 
Entering  self-assignment 

DogHouse  operator=  : [copy-constructed  FidoHouse] 

contains  [Fido] , rc  = 3 
After  self-assignment 
bobs: [copy-constructed  FidoHouse] 
contains  [Fido] , rc  = 3 
Entering  rename ( "Bob" ) 

After  rename ( "Bob" ) 

DogHouse  destructor:  [copy-constructed  FidoHouse] 

contains  [Fido] , rc  = 3 
Detaching  Dog:  [Fido],  rc  = 3 

DogHouse  destructor:  [FidoHouse  assigned] 

contains  [Fido] , rc  = 2 
Detaching  Dog:  [Fido],  rc  = 2 

DogHouse  destructor:  [FidoHouse] 

contains  [Fido] , rc  = 1 
Detaching  Dog:  [Fido],  rc  = 1 

Deleting  Dog:  [Fido],  rc  = 0 
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By  studying  the  output,  tracing  through  the  source  code,  and 
experimenting  with  the  program,  you'll  deepen  your 
understanding  of  these  techniques. 

Automatic  operator=  creation 

Because  assigning  an  object  to  another  object  of  the  same  type  is  an 
activity  most  people  expect  to  be  possible,  the  compiler  will 
automatically  create  a type::operator=(type)f  you  don't  make  one. 
The  behavior  of  this  operator  mi  mi  cs  that  of  the  automatical  I y 
created  copy-constructor;  if  the  cl  ass  contains  objects  (or  is 
inherited  from  another  class),  the operator=for  those  objects  is 
called  recursively.  This  is  called  memberwise  assignment.  For 
example, 

/ / : C12 : AutomaticOperatorEquals . cpp 
#include  <iostream> 
using  namespace  std; 

class  Cargo  { 
public : 

Cargos  operator= (const  Cargos)  { 

cout  <<  "inside  Cargo :: operator=  () " <<  endl; 
return  *this; 


}; 


class  Truck  { 

Cargo  b; 

}; 

int  main  ( ) { 

Truck  a,  b; 

a = b;  //  Prints:  "inside  Cargo :: operator=  () " 

} ///:- 

The  automati  cal  I y generated  operator=for  T ruck  cal  I s 
Cargo::operator? 

In  general,  you  don't  want  to  let  the  compiler  do  this  for  you.  With 
classes  of  any  sophistication  (especially  if  they  contain  pointers!) 
you  want  to  explicitly  create  an  operator^  If  you  really  don't  want 
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people  to  perform  assignment,  declareoperator=as  a private 
function.  (You  don't  need  to  define  it  unless  you're  using  it  inside 
the  cl  ass.) 


Automatic  type  conversion 

In  C and  C++,  if  the  compiler  sees  an  expression  or  function  call 
using  a type  that  isn't  quitethe  one  it  needs,  it  can  often  perform  an 
automatic  type  conversion  from  the  type  it  has  to  the  type  it  wants. 
In  C++,  you  can  achieve  this  same  effect  for  user-defined  types  by 
defining  automatic  type  conversion  functions.  These  functions 
come  in  two  flavors:  a particular  type  of  constructor  and  an 
overloaded  operator. 

Constructor  conversion 

If  you  defi  ne  a constructor  that  takes  as  its  single  argument  an 
object  (or  reference)  of  another  type,  that  constructor  al  I ows  the 
compiler  to  perform  an  automatic  type  conversion.  For  example, 

/ / : C12 : AutomaticTypeConversion . cpp 
//  Type  conversion  constructor 
class  One  { 
public : 

OneO  {} 

}; 


class  Two  { 
public : 

Two (const  One&)  {} 

}; 


void  f (Two)  { } 

int  main ( ) { 

One  one; 

f (one) ; //  Wants  a Two,  has  a One 
} ///:- 
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When  the  compiler  sees f( ) cal  led  with  aOneobject,  it  looks  at  the 
declaration  for  f(  )and  notices  it  wants  a Two.  Then  it  looks  to  see 
if  there's  any  way  to  get  a Two  from  a 0 no  and  it  finds  the 
constructor  T wo::T  wo(0  ne)  which  it  quietly  cal  Is.  The  resulting 
T wo  object  is  handed  to  f( ). 

I n this  case,  automatic  type  conversion  has  saved  you  from  the 
troubleof  defining  two  overloaded  versions  of  f( ).  However,  the 
cost  is  the  hidden  constructor  call  to  Two,  which  may  matter  if 
you're  concerned  about  the  efficiency  of  cal  Is  to  f( ). 

Preventing  constructor  conversion 

There  are  times  when  automatic  type  conversion  via  the 
constructor  can  cause  problems.  To  turn  it  off,  you  modify  the 
constructor  by  prefacing  with  the  keyword  expiicit(which  only 
works  with  constructors).  Used  to  modify  the  constructor  of  class 
T wo  i n the  exampi  e above: 

//:  C12 : ExplicitKeyword . cpp 
//  Using  the  "explicit"  keyword 
class  One  { 
public : 

OneO  {} 

}; 


class  Two  { 
public : 

explicit  Two (const  One&)  {} 

}; 


void  f (Two)  { } 

int  main ( ) { 

One  one; 

//!  f (one) ; //  No  auto  conversion  allowed 

f (Two (one));  //  OK  — user  performs  conversion 

} ///:- 

By  making  Two's  constructor  explicit,  thecompiler  istold  not  to 
perform  any  automatic  conversion  using  that  particular  constructor 
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(other  non-explicitconstructors  in  that  class  can  still  perform 
automatic  conversions).  If  the  user  wants  to  make  the  conversion 
happen,  the  code  must  be  written  out.  I n the  code  above, 
f (T  wo(one))creates  a temporary  object  of  type  T wo  from  one,  just 
I ike  the  compiler  did  in  the  previous  version. 

Operator  conversion 

The  second  way  to  produce  automatic  type  conversion  is  through 
operator  overloading.  You  can  create  a member  function  that  takes 
the  current  type  and  converts  it  to  the  desired  type  using  the 
operatorkeyword  followed  by  the  type  you  want  to  convert  to. 
This  form  of  operator  overloading  is  unique  because  you  don't 
appear  to  specify  a return  type  - the  return  type  is  the  name  of  the 
operator  you're  overloading.  Here's  an  example: 

/ / : C12 : OperatorOverloadingConversion . cpp 
class  Three  { 
int  i ; 
public : 

Three  (int  11  = 0,  int  = 0)  : 1(11)  {} 

}; 

class  Four  { 
int  X ; 
public : 

Four  (int  xx)  : x(xx)  {} 

operator  Three ()  const  { return  Three (x) ; } 

}; 


void  g (Three)  { } 

int  main  ( ) { 

Four  four  ( 1 ) ; 
g (four) ; 

g(l);  //  Calls  Three(l,0) 

} ///:- 

With  the  constructor  technique,  the  destination  class  is  performing 
the  conversion,  but  with  operators,  the  source  class  performs  the 
conversi  on.  The  val  ue  of  the  constructor  techni  que  i s that  you  can 
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add  a new  conversion  path  to  an  existing  systenn  as  you're  creating 
a new  class.  However,  creating  a single-argument  constructor 
a/n/ays  defines  an  automatic  type  conversion  (even  if  it's  got  more 
than  one  argument,  if  the  rest  of  the  arguments  are  defaulted), 
which  may  not  be  what  you  want  (in  which  case  you  can  turn  it  off 
using  explicit-  In  addition,  there's  no  way  to  use  a constructor 
conversion  from  a user-defined  type  to  a built-in  type;  this  is 
possi  bl  e on  I y w i th  operator  over  I oad  i ng . 

Reflexivity 

One  of  the  most  convenient  reasons  to  use  global  overloaded 
operators  instead  of  member  operators  is  that  in  the  global 
versions,  automatic  type  conversion  may  be  applied  to  either 
operand,  whereas  with  member  objects,  the  left-hand  operand  must 
already  bethe  proper  type.  If  you  want  both  operandsto  be 
converted,  the  global  versions  can  savea  lot  of  coding.  Here's  a 
small  example: 

// : C12 : Ref lexivityInOverloading . cpp 
class  Number  { 
int  i ; 
public : 

Number (int  11  = 0)  : 1(11)  {} 

const  Number 

operator!  (const  Numbers  n)  const  { 
return  Number (1  + n.i); 

} 

friend  const  Number 

operator- (const  Numbers,  const  Numbers); 

}; 


const  Number 

operator- (const  Numbers  nl, 

const  Numbers  n2)  { 

return  Number (nl.i  - n2.i); 

} 

int  main  ( ) { 

Number  a(47),  b(ll); 
a + b;  //OK 

a t 1;  //  2nd  arg  converted  to  Number 
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//!  1 + a;  //  Wrong!  1st  arg  not  of  type  Number 
a - b;  //OK 

a - 1;  //  2nd  arg  converted  to  Number 
1 - a;  //  1st  arg  converted  to  Number 
} ///:- 

Class  N umberhas  both  a member  operator+and  a friend 
operator-.  Because  there's  a constructor  that  takes  a single  int 
argument,  an  int  can  be  automatically  converted  to  a N umber  but 
only  under  the  right  conditions.  In  main( ) you  can  see  that  adding 
a N umberto  another  N umberworksfine  because  it's  an  exact 
match  to  the  overloaded  operator.  Also,  when  the  compiler  sees  a 
Numberfollowed  by  a + and  an  int  it  can  match  to  the  member 
function  Numbenioperator-land  convert  the  intargument  to  a 
Number  using  the  constructor.  But  when  it  sees  an  int,a+,  and  a 
Number,  it  doesn't  know  what  to  do  because  all  it  has  is 
Number::operatorf  which  requires  that  the  I eft  operand  already 
bea  Numberobject.  Thus,  the  compiler  issues  an  error. 

With  the  friend  operator-,  things  are  different.  The  compiler  needs 
to  fill  in  both  its  arguments  however  it  can;  it  isn't  restricted  to 
having  a Numberas  the  left-hand  argument.  Thus,  if  it  sees 

1 - a 

it  can  convert  the  fi  rst  argument  to  a N umber  using  the 
constructor. 

Sometimes  you  want  to  be  able  to  restricttheuseof  your  operators 
by  making  them  members.  For  example,  when  multiplying  a matrix 
by  a vector,  the  vector  must  go  on  the  right.  But  if  you  want  your 
operators  to  be  able  to  convert  either  argument,  make  the  operator 
a friend  function. 

Fortunately,  thecompiler  will  nottakel-  land  convert  both 
arguments  to  Numberobjects  and  then  call  operator-.  That  would 
mean  that  existing  C code  might  suddenly  start  to  work  differently. 
Thecompiler  matches  the"simplest"  possibility  first,  which  isthe 
built-in  operator  for  the  expression  1-1 
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Type  conversion  example 

An  example  in  which  automatic  type  conversion  is  extremely 
helpful  occurs  with  any  classthat  encapsulates  character  strings  (in 
thiscase,  wewill  just  implement  the  class  using  the  Standard  C++ 
stringclass  because  it's  simple).  Without  automatic  type 
conversion,  if  you  want  to  use  all  the  existing  string  functions  from 
the  Standard  C library,  you  have  to  create  a member  function  for 
each  one,  I ike  this: 

//:  C12 : Stringsl . cpp 
//  No  auto  type  conversion 
#include  /require . h" 

#include  <cstring> 

#include  <cstdlib> 

#include  <string> 
using  namespace  std; 

class  Strings  { 
string  s; 
public : 

Strings (const  strings  str  = "")  : s(str)  {} 

int  strcmp (const  StringcS  S)  const  { 

return  :: strcmp ( s . c_str () , S . s . c_str ( ) ) ; 

} 

//  ...  etc.,  for  every  function  in  string. h 

}; 


int  main  ( ) { 

Strings  si ("hello"),  s2 ("there"); 
si . strcmp (s2) ; 

} ///:- 

Here,  only  the strcmp(  )function  is  created,  but  you'd  haveto 
create  a corresponding  function  for  every  one  in  <cstring>that 
might  be  needed.  Fortunately,  you  can  provide  an  automatic  type 
conversion  allowing  access  to  all  the  functions  in  <cstring> 

//:  C12 : Strings2 . cpp 
//  With  auto  type  conversion 
#include  ".. /require . h" 

#include  <cstring> 

#include  <cstdlib> 
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#include  <string> 
using  namespace  std; 

class  Strings  { 
string  s; 
public : 

Strings (const  strings  str  = "")  : s(str)  {} 

operator  const  char*()  const  { 
return  s.c_str(); 


}; 


int  main  ( ) { 

Strings  si  ("hello") /■  s2  ("there"); 
strcmp(sl,  s2);  //  Standard  C function 
strspn(sl,  s2);  //  Any  string  function! 

} ///:- 

Now  any  function  that  takes  a char* argument  can  also  take  a 
Stringcargument  becausethe compiler  knows  how  to  make  a char* 
from  aStringc 

Pitfalls  in  automatic  type  conversion 

Becausethe  compiler  must  choose  how  to  quietly  perform  a type 
conversion,  it  can  get  into  trouble  if  you  don't  design  your 
conversions  correctly.  A simple  and  obvious  situation  occurs  with  a 
cl  ass  X that  can  convert  itself  to  an  object  of  cl  ass  Y with  an 
operator  Y( ) If  class  Y has  a constructor  that  takes  a single 
argument  of  type  X,  this  represents  the  identical  type  conversion. 
The  compiler  now  hastwo  waystogofromXtoY,  so  it  will 
generate  an  ambiguity  error  when  that  conversion  occurs: 

/ / : C12 : TypeConversionAmbiguity . cpp 
class  Orange;  //  Class  declaration 

class  Apple  { 
public : 

operator  Orange ()  const;  //  Convert  Apple  to  Orange 

}; 


class  Orange  { 
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public : 

Orange (Apple ) ; //  Convert  Apple  to  Orange 

}; 


void  f (Orange)  { } 

int  main  ( ) { 

Apple  a; 

//!  f (a) ; //  Error:  ambiguous  conversion 

} ///:- 

The  obvious  solution  to  this  problenn  isnotto  (do  it.  Just  provi(dea 
single  path  for  automatic  conversion  from  one  type  to  another. 

A more  difficult  problem  to  spot  occurs  when  you  provide 
automatic  conversion  to  more  than  one  type.  This  is  sometimes 
called  fan-out: 


1 1 \ C12 : TypeConversionFanout . cpp 
class  Orange  { } ; 
class  Pear  { } ; 


class  Apple  { 
public : 

operator  Orange ()  const; 
operator  Pear()  const; 


//  Overloaded  eat(): 
void  eat (Orange) ; 
void  eat (Pear) ; 

int  main  ( ) { 

Apple  c; 

// ! eat (c) ; 

//  Error:  Apple  ->  Orange  or  Apple  ->  Pear  ??? 

} ///:- 

ClassApplehas  automatic  conversions  to  both  0 rangeand  Pear. 
Theinsidiousthing  about  this  is  that  there's  no  problem  until 
someone  innocently  comes  along  and  creates  two  overloaded 
versions  of  eat( ) (With  only  oneversion,  the  codein  main(  )works 
fine.) 
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Again,  the  solution  - and  the  general  watchword  with  automatic 
type  conversion  - is  to  provide  only  a single  automatic  conversion 
from  one  type  to  another.  You  can  have  conversions  to  other  types; 
they  just  shouldn't  be  automat/c.  You  can  create  explicit  function 
calls  with  names  like  makeA(  )and  makeB( ) 

Hidden  activities 

Automatic  type  conversion  can  introduce  more  underlying 
activities  than  you  may  expect.  Asa  little  brain  teaser,  look  at  this 
mod  if  I cat!  on  of  C opy  i ngV  si  n i ti  ai  i zati  on  .cpp 

// : C12 : CopyingVsInitialization2 . cpp 
class  Fi  { } ; 

class  Fee  { 
public : 

Fee ( int ) { } 

Fee (const  F1& ) { } 

}; 


class  Fo  { 
int  1 ; 
public : 

Fo  (int  X = 0)  : 1 (x)  { } 

operator  Fee()  const  { return  Fee(i);  } 

}; 


int  main  ( ) { 

Fo  f o; 

Fee  fee  = fo; 

} ///:- 

There  is  no  constructor  to  create  the  Fee  feefrom  a Fo  object. 

H owever,  Fo  has  an  automatic  type  conversion  to  a Fee  There's  no 
copy-constructor  to  create  a Feefrom  a Fee  but  this  is  one  of  the 
special  functions  the  compiler  can  create  for  you.  (The  default 
constructor,  copy-constructor,  operator^  and  destructor  can  be 
synthesized  automatically  by  the  compiler.)  So  for  the  relatively 
innocuous  statement 

Fee  fee  = fo; 
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the  automatic  type  conversion  operator  iscaiied,  and  a copy- 
constructor  is  created. 

Use  automatic  type  conversion  carefuiiy.  As  with  aii  operator 
overioading,  it's  exceiient  when  itsignificantiy  reduces  a coding 
task,  but  it's  usuaiiy  not  worth  using  gratuitousiy. 


Summary 

The  w hoi  e reason  for  the  exi  stence  of  operator  overi  oad  i ng  i s for 
those  situations  when  it  makes  iife easier.  There's  nothing 
particuiariy  magicai  about  it;  theoverioaded  operators  arejust 
functions  with  funny  names,  and  the  function  cai  is  happen  to  be 
madeforyou  by  thecompiier  when  it  spots  the  right  pattern.  But  if 
operator  overioading  doesn't  provide  a significant  benefit  to  you 
(the  creator  of  the  dass)  or  the  user  of  the  ciass,  don't  confuse  the 
issue  by  adding  it. 


Exercises 

Solutions  to  selected  exercises  can  be  found  in  the  electronic  document  TheThinking  in  C++ Annotated 
Solution  Guide,  aval  I able  for  a small  feefromwww.BruceEckel.com. 

1.  Create  a si  mpie  dass  with  an  overioaded  operator++Try 
caiiing  this  operator  in  both  pre-  and  postfix  form  and 
see  what  kind  of  compiier  warning  you  get. 

2.  Create  a si  mpie  ciass  containing  an  inland  overioad  the 
operator+asa  member  function.  A iso  provide  a print( ) 
member  function  that  takes  an  ostream&asan  argument 
and  prints  to  that  ostream&  Test  your  ciass  to  show  that 
it  works  correctiy. 

3 . Add  a bi  nary  operator-to  Exerci se  2 as  a member 
function.  Demonstrate  that  you  can  use  your  objects  in 
compi  ex  express!  ons  i i ke 

a + b - c 
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4.  Add  an  operator++and  operator--to  Exercise  2,  both  the 
prefix  and  the  postfix  versions,  such  that  they  return  the 
incrennented  or  decrennented  object.  Make  sure  that  the 
postfix  versions  return  the  correct  value. 

5.  Modify  the  incrennent  and  decrennent  operators  in 
Exercise 4 so  that  the  prefix  versions  return  a non-const 
reference  and  the  postfix  versions  return  a constobject. 
Show  that  they  work  correctly  and  explain  why  this 
would  be  done  in  practice. 

6.  Changetheprint(  )function  in  Exercise  2 so  that  it  is  the 
overloaded  operator «as  i n 

lostreamO  peratorO  verloading.cpp 

7 . M od  ify  Exerd se  3 so  that  the  operator+and  operator-are 
non-mennber  functions.  Dennonstrate that  they  still  work 
correctly. 

8.  Add  the  unary  operator-to  Exercise  2 and  dennonstrate 
that  it  works  correctly. 

9 . C reate  a cl  ass  that  contai  ns  a si  ngl  e pri  vatechar. 

Overload  the  iostream  operators  « and  » (as  in 

lostreamO  peratorOverloading.CF^psnd  test  thenn.  You 
can  test  thenn  with  f streams  stringstreans,  and  cin  and 
cout 

10.  Determine  the  dummy  constant  value  that  your  compiler 
passes  for  postfix  operator++and  operator--; 

11.  Write  a Numberclass  that  holds  a double  and  add 

overloaded  operators  for  +,  *,  / and  assignment. 

Choose  the  retu  rn  val  ues  for  these  fu  ncti  ons  so  that 
expressions  can  be  chained  together,  and  for  efficiency. 
Write  an  automatic  type  conversion  operator  int( ) 

12.  Modify  Exercise  11  so  that  the  return  value  optimization  is 
used,  if  you  have  not  already  done  so. 

13.  Create  a class  that  contains  a poi  nter,  and  demonstrate 
that  if  you  allow  the  compiler  to  synthesize  the  operator= 
the  resu It  of  usi ng  that  operator  will  be  poi nters  that  are 
al  i ased  to  the  same  storage.  N ow  f i x the  probi  em  by 
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defining  your  own  operator=and  demonstrate  that  it 
corrects  the  aliasing.  Make  sure  you  check  for  self- 
assignment and  handlethat  case  properly. 

14.  Write  a class  called  Bird  that  contains  a string  member 
and  astatic  int  In  the  default  constructor,  usetheintto 
automatically  generate  an  identifier  that  you  build  in  the 
string  along  with  the  name  of  the  cl  ass  (Bird  #lBird  #Z 
etc.).  Add  an  operator«for  ostreams  to  pri  nt  out  the 
Bird  objects.  Write  an  assignment  operator=and  a copy- 
constructor.  In  main( ) verify  that  everything  works 
correctly. 

15.  Write  a class  called  BirdHousethat  contains  an  object,  a 
poi  nter  and  a reference  for  class  Bird  from  Exercise  14. 
The  constructor  should  takethethree  Birds  as 
arguments.  Add  an  operator«for  ostreams  for 
BirdHouse  Disallow  the  assignment  operator=and 
copy-constructor.  In  main( ) verify  that  everything 
works  correctly.  Make  sure  that  you  can  chain 
assignments  for  BirdHouseobjects  and  build  expressions 
involving  multi  pie  operators. 

16.  Add  an  intdata  member  to  both  Bird  and  BirdHousein 
Exercise  15.  Add  member  operators  +,  -,  *,  and  / that  use 
the  i nt  members  to  perform  the  operati  ons  on  the 
respective  members.  Verify  that  these  work. 

1 7 . Repeat  Exerd  se  16  usi  ng  non-member  operators. 

18.  Add  an  operator--to  SmartPointer.cppand 
N ested  S martPoi  nter.cpp 

19.  Modify  CopyingVslnitiaiization.cppo  that  all  of  the 

constructors  print  a message  that  tel  Is  you  what's  going 
on.  Now  verify  that  the  two  forms  of  cal  Is  to  the  copy- 
constructor  (the  assignment  form  and  the  parenthesized 
form)  are  equivalent. 

20.  Attempt  to  create  a non-member  operator=for  a class 
and  see  what  kind  of  compiler  message  you  get. 

21.  C reate  a cl  ass  with  an  assi  gnment  operator  that  has  a 
second  argument,  astringthathasadefauitvaluethat 
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says  "op=call."  Create  a function  that  assigns  an  object 
of  your  cl  ass  to  another  one  and  show  that  your 
assignment  operator  is  cal  led  correctly. 

22.  In  CopyingWithPointers.cppremovetheoperator=in 
DogHouseand  show  that  the  compiler-synthesized 
operator=correctly  copies  the  string  but  simply  aliases 
the  Dog  pointer. 

23.  In  ReferenceCounting.cppadd  astatic  intend  an 

ordinary  intas  data  members  to  both  D og  and 
DogHouse  In  all  constructors  for  both  classes,  increment 
the  static  intend  assign  theresuitto  the  ordinary  intto 
keep  track  of  the  number  of  objects  that  have  been 
created.  M akethe  necessary  modifications  so  that  all  the 
printing  statements  will  say  the  int  identifiers  of  the 
objects  involved. 

24.  C reate  a cl  ass  contai  n i n g a stri  n g as  a d ata  member . 

I niti  al  ize  the  stri  ng  i n the  constructor,  but  do  not  create  a 
copy-constructor  or  operators  M ake  a second  class  that 
has  a member  object  of  your  fi  rst  class;  do  not  create  a 
copy-constructor  or  operator^for  this  class  either. 
Demonstrate  that  the  copy-constructor  and  operator=are 
properly  synthesized  by  the  compiler. 

25.  Combinetheclassesin  OverioadingUnaryOperatorsxpp 
and  Integer.cpp 

26.  M odify  PointerT oM  emberO peratorxpby  adding  two 
new  member  f u ncti  ons  to  D og  that  take  no  argu  ments 
and  return  void.  Create  and  test  an  overloaded 
operator->*that  works  with  your  two  new  functions. 

27.  Add  an  operator- >*to  NestedSmartPointerxpp 

28.  Createtwoclasses,  Appieand  Orange  In  Appie  create  a 
constructor  that  takes  an  0 rangeas  an  argument.  Create 
a function  that  takes  an  Appieand  call  that  function  with 
an  Orangeto  show  that  it  works.  Now  maketheAppie 
constructor  expiicitto  demonstrate  that  the  automatic 
type  conversion  is  thus  prevented.  Modify  the  cal  I to 
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yourfunction  so  that  the  conversion  is  madeexplidtly 
and  thus  succeeds. 

29.  Add  a giobai  operator*to  ReflexivityInOverloading.cpp 

and  demonstrate  that  it  is  refiexive. 

30.  Create  two  ci asses  and  create  an  operator+and  the 
conversion  functions  such  that  addition  is  refiexivefor 
the  two  ci  asses. 

31.  FixTypeConversionFanoutxpilDy  creating  an  expiicit 
function  to  caii  to  perform  the  type  conversion,  instead  of 
one  of  the  automati  c conversi  on  operators. 

32.  Write  si  mpie  code  that  uses  the +,  *,  and  / operators  for 
doubles.  Figure  out  how  your  compiier  generates 
assembiy  code  and  iook  attheassembiy  ianguage  that's 
generated  to  discover  and  expiain  what's  going  on  under 
the  hood. 
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13:  Dynamic  Object 
Creation 

Sometimes  you  know  the  exact  quantity,  type,  and 
lifetime  of  the  objects  in  your  program.  But  not  always. 
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How  many  planes  will  an  air-traffic  system  need  to  handle?  How 
many  shapes  wi  1 1 a CA  D system  use?  H ow  many  nodes  will  there 
be  I n a network? 

To  solve  the  general  programming  problem,  it'sessential  that  you 
be  able  to  create  and  destroy  objects  at  runtime.  Of  course,  C has 
always  provided  the  dynamic  memory  allocation  functions  malloc( ) 
and  free(  )(along  with  variants  of  mall oc( ) that  allocate  storage 
from  the  heap  (also  cal  led  the  free  store)  at  runti  me. 

However,  this  simply  won't  work  in  C-H-.  The  constructor  doesn't 
allow  you  to  hand  ittheaddressof  the  memory  to  initialize,  and  for 
good  reason.  If  you  could  do  that,  you  might: 

1.  Forget.  Then  guaranteed  initialization  of  objects  in  C-H- 
wouldn't  be  guaranteed. 

2.  Accidentally  do  something  to  the  object  before  you  initialize 
it,  expecting  the  right  thing  to  happen. 

3.  Hand  it  the  wrong-sized  object. 

And  of  course,  even  if  you  did  everything  correctly,  anyone  who 
modifies  your  program  is  prone  to  the  same  errors.  Improper 
initialization  is  responsible  for  a large  portion  of  programming 
problems,  so  it's  especially  important  to  guarantee  constructor  calls 
for  objects  created  on  the  heap. 

So  how  does  C-H-guarantee  proper  initialization  and  cleanup,  but 
allow  you  to  create  objects  dynamically  on  the  heap? 

The  answer  is  by  bringing  dynamic  object  creation  i nto  the  core  of 
the  language.  malloc(  )and  free(  )are  library  functions,  and  thus 
outside  the  control  of  the  compiler.  However,  if  you  have  an 
operator  to  perform  the  combined  act  of  dynamic  storage  allocation 
and  initialization  and  another  operator  to  perform  the  combi  ned  act 
of  cleanup  and  releasing  storage,  the  compiler  can  still  guarantee 
that  constructors  and  destructors  will  be  cal  led  for  all  objects. 
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In  this  chapter,  you'll  learn  how  C++'snewand  deleteelegantly 
solve  this  problem  by  safely  creating  objects  on  the  heap. 


Object  creation 

When  a C-H-object  is  created,  two  events  occur: 

1 . Storage  i s al  I ocated  for  the  object. 

2.  The  constructor  is  called  to  initializethat  storage. 

By  now  you  should  believe  that  step  two  always  happens.  C++ 

enforces  it  because  uninitialized  objects  are  a major  source  of 

program  bugs.  It  doesn't  matter  where  or  how  the  object  is  created 

- the  constructor  is  always  cal  led. 

Step  one,  however,  can  occur  in  several  ways,  or  at  alternate  times: 

1 . Storage  can  be  al  I ocated  before  the  program  begi  ns,  i n the 
stati c storage  area.  Thi s storage  exists  for  the  I ife  of  the 
program. 

2 . Storage  can  be  created  on  the  stack  w henever  a parti  cu  I ar 
execution  point  is  reached  (an  opening  brace).  That  storage  is 
rel eased  automati cal  ly  at  the  compi ementary  executi on  poi  nt 
(theclosing  brace).  These  stack-allocation  operations  are  built 
into  the  instruction  set  of  the  processor  and  are  very  efficient. 
However,  you  have  to  know  exactly  how  many  variables  you 
need  when  you're  writi  ng  the  program  so  the  compi  ler  can 
generate  the  right  code. 

3 . Storage  can  be  al  I ocated  from  a pool  of  memory  cal  I ed  the 
heap  (also  known  as  the  free  store).  Thi  sis  cal  led  dynamic 
memory  allocation.  To  allocate  this  memory,  a function  is 
called  at  runtime;  this  means  you  can  decide  at  any  time  that 
you  want  some  memory  and  how  much  you  need.  You  are 
also  responsible  for  determining  when  to  rel  ease  the 
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memory,  which  means  the  lifetime  of  that  memory  can  be  as 
long  as  you  choose  - it  isn't  determined  by  scope. 

Often  these  three  regi  ons  are  placed  i n a si  ngl  e conti  guous  piece  of 
physical  memory:  the  static  area,  the  stack,  and  the  heap  (in  an 
order  determined  by  the  compiler  writer).  However,  there  are  no 
rules.  The  stack  may  be  in  a special  place,  and  the  heap  may  be 
implemented  by  making  cal  Is  for  chunks  of  memory  from  the 
operating  system.  Asa  programmer,  these  things  are  normally 
shielded  from  you,  so  all  you  need  to  think  about  is  that  the 
memory  is  there  when  you  call  for  it. 

C's  approach  to  the  heap 

To  allocate  memory  dynamically  at  runtime,  C provides  functions 
in  its  standard  library:  malloc(  )and  its  variants  call  oc(  )and 
realloc(  yto  produce  memory  from  the  heap,  and  free(  )to  release 
the  memory  back  to  the  heap.  Thesefunctions  are  pragmatic  but 
primitive  and  require  understanding  and  care  on  the  part  of  the 
programmer.  To  create  an  instanceof  a classon  the  heap  using  C's 
dynamic  memory  functions,  you'd  have  to  do  something  likethis: 

//:  C13 :MallocClass . cpp 

//  Malloc  with  class  objects 

//  What  you'd  have  to  do  if  not  for  "new" 

#include  ".. /require . h" 

#include  <cstdlib>  //  malloc ()  & free() 

#include  <cstring>  //  memsetO 
#include  <iostream> 
using  namespace  std; 

class  Obj  { 
int  i,  j,  k; 
enum  { sz  = 100  } ; 
char  buf [ sz ] ; 
public : 

void  initialize  0 { //  Can't  use  constructor 

cout  <<  "initializing  Obj"  <<  endl; 
i = j = k = 0; 
memset (buf , 0,  sz); 

} 
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void  destroyO  const  { //  Can't  use  destructor 
cout  <<  "destroying  Obj"  <<  endl; 


}; 


int  main  ( ) { 

Obj*  obj  = (Ob j * ) malloc ( sizeof (Ob j ) ) ; 
require (obj  !=  0); 
ob j->initialize ()  ; 

//  ...  sometime  later: 
ob j->destroy ( ) ; 
free (ob j ) ; 

} ///:- 

Y ou  can  see  the  use  of  mal  loc(  )to  create  storage  for  the  object  i n 
the  line: 

Obj*  obj  = (Ob j *) malloc ( sizeof (Ob j ))  ; 

H ere,  the  user  must  determi  ne  the  size  of  the  object  (one  place  for 
an  error).  malloc(  )returns  a void*  because  it  just  produces  a patch 
of  memory,  notan  object.  C++doesn't  allow  avoid*to  be  assigned 
to  any  other  pointer,  so  it  must  be  cast. 

Because  mal loc(  )may  fail  to  find  any  memory  (in  which  case  it 
returns  zero),  you  must  check  the  returned  pointer  to  make  sure  it 
was  successful. 

But  the  worst  problem  is  this  line: 

Ob j->initialize  () ; 

If  users  make  it  this  far  correctly,  they  must  remember  to  i nitial  ize 
the  object  before  it  is  used.  Notice  that  a constructor  was  not  used 
because  the  constructor  cannot  be  called  explicitly^-  it'scalled  for 
you  by  the  compiler  when  an  object  is  created.  The  problem  here  is 
that  the  user  now  has  the  option  to  forget  to  perform  the 


^ There  is  a special  syntax  called  p/acemenf  new  thatallowsyou  to  call  aconstructor 
for  a pre-all ocated  pieceof  memory.  This  is  introduced  later  in  the  chapter. 
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initialization  before  the  object  is  used,  thus  reintroducing  a major 
source  of  bugs. 

It  also  turns  out  that  many  programmers  seem  to  fi  nd  C's  dynamic 
memory  functions  too  confusing  and  complicated;  it's  not 
uncommon  to  find  C programmers  who  use  virtual  memory 
machines  al  locati  ng  huge  arrays  of  variables  in  the  static  storage 
area  to  avoid  thinking  about  dynamic  memory  allocation.  Because 
C ++  i s attempt!  ng  to  make  I i brary  use  safe  and  efforti  ess  for  the 
casual  programmer,  C's  approach  to  dynamic  memory  is 
unacceptable. 

operator  new 

The  sol  uti  on  i n C ++  i s to  combi  ne  al  I the  act!  ons  necessary  to  create 
an  object  into  a si  ngle  operator  cal  led  new.  When  you  create  an 
object  with  new  (using  a new-expression),  it  allocates  enough  storage 
on  the  heap  to  hoi  d the  object  and  cal  I s the  constructor  for  that 
storage.  Thus,  if  you  say 

I MyType  *fp  = new  MyType(l,2); 

at  ru  nti  me,  the  equ  i val  ent  of  mal  I oc(si  zeof  (M  yT y pe))s  cal  I ed 
(often,  it  is  literally  a call  to  malloc( ),  and  the  constructor  for 
MyTypeiscalled  with  the  resulting  address  as  the  this  pointer, 
using  (1,2)  as  the  argument  list.  By  the  time  the  pointer  is  assigned 
tofp,  it's  a live,  initialized  object  - you  can't  even  get  your  hands 
on  it  before  then.  I t's  al  so  automat!  cal  I y the  proper  MyTypety  peso 
no  cast  is  necessary. 

The  default  new  checks  to  make  sure  the  memory  allocation  was 
successful  before  passing  the  address  to  the  constructor,  so  you 
don't  haveto  explicitly  determine  if  the  call  was  successful.  Later  in 
the  chapter  you'll  find  out  what  happens  if  there's  no  memory  left. 

You  can  create  a new-expression  using  any  constructor  available 
for  the  class.  If  the  constructor  has  no  arguments,  you  write  the 
new-expression  without  the  constructor  argument  list: 
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MyType  *fp  = new  MyType; 


N otice  how  simple  the  process  of  creati  ng  objects  on  the  heap 
becomes  - a single  express!  on,  with  all  the  sizing,  conversions,  and 
safety  checks  built  in.  It's  as  easy  to  create  an  object  on  the  heap  as 
it  is  on  the  stack. 

operator  delete 

The  complement  to  the  new-expression  is  the  deld:e&(pres5ion, 
which  first  cal  Is  the  destructor  and  then  releases  the  memory  (often 
with  a call  tofree(  J.  Just  as  a new-expression  returns  a pointer  to 
the  object,  a delete-expression  requirestheaddressof  an  object. 

I delete  fp; 

This  destructs  and  then  releases  the  storage  for  the  dynamically 
allocated  M yTypeobject  created  earlier. 

deletecan  be  cal  led  only  for  an  object  created  by  new.  If  you 
malloc(  )(or  calloc(  )or  realloc( ) an  object  and  then  deleteit,  the 

behavior  is  undefined.  Because  most  default  implementations  of 
new  and  deleteusemalloc(  )and  free( ) you'd  probably  end  up 
rel  easi  ng  the  memory  w ithout  cal  I i ng  the  destructor. 

If  the  pointer  you 're  deleting  iszero,  nothing  will  happen.  For  this 
reason,  people  often  recommend  setting  a pointer  to  zero 
immediately  after  you  delete  it,  to  prevent  deleting  it  twice. 
Deleting  an  object  more  than  once  is  definitely  a bad  thing  to  do, 
and  will  cause  problems. 

A simple  example 

This  example  shows  that  initialization  takes  place: 

//:  C13:Tree.h 
#ifndef  TREE_H 
#define  TREE_H 
#include  <iostream> 
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class  Tree  { 
int  height; 
public : 

Tree  (int  treeHeight)  : height (treeHeight ) {} 

~Tree()  { std::cout  <<  } 

friend  std : : ostream& 

operator<< ( std : : ostream&  os,  const  Tree*  t)  { 
return  os  <<  "Tree  height  is:  " 

<<  t->height  <<  std::endl; 


}; 

#endif  //  TREE_H  ///:- 

//:  C13 : NewAndDelete . cpp 
//  Simple  demo  of  new  & delete 
#include  "Tree.h" 
using  namespace  std; 

int  main  ( ) { 

Tree*  t = new  Tree  (40); 
cout  <<  t; 
delete  t; 

} ///:- 

We  can  prove  that  the  constructor  is  cal  led  by  printing  out  the 
value  of  the  Tree  Here,  it's  done  by  overloading  theoperator«to 
use  with  an  ostreamand  a Tree*.  Note,  however,  that  even  though 
thefunction  is  declared  as  a friend,  it  is  defined  as  an  inline!  This  is 
a mere  convenience-  defining  a friendfunction  as  an  inline  to  a 
class  doesn't  change  the  friend  status  or  the  fact  that  it's  a global 
function  and  not  a class  member  function.  Also  notice  that  the 
return  value  is  the  result  of  the  entire  output  expression,  which  is 
an  ostream& (which  it  must  be,  to  satisfy  the  return  value  type  of 
thefunction). 


Memory  manager  overhead 

When  you  create  automatic  objects  on  the  stack,  the  size  of  the 
objects  and  their  lifetime  is  built  right  into  the  generated  code, 
because  the  compiler  knows  the  exact  type,  quantity,  and  scope. 
Creating  objects  on  the  heap  involves  additional  overhead,  both  in 
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time  and  in  space.  Here's  a typical  scenario.  (You  can  replace 

malloc(  )with  calloc(  )or  realloc( )) 

You  call  malloc( ) which  requests  a block  of  memory  from  the 
pool.  (Thiscode  may  actually  be  part  of  mall oc( )) 

The  pool  is  searched  for  a block  of  memory  large  enough  to  satisfy 
the  request.  This  is  done  by  checking  a map  or  directory  of  some 
sort  that  shows  which  blocks  are  currently  in  use  and  which  are 
available.  It's  a quick  process,  but  it  may  take  several  tries  so  it 
might  not  be  deterministic  - that  is,  you  can't  necessarily  counton 
malloc(  )al  ways  taking  exactly  the  same  amount  of  time. 

Before  a poi  nter  to  that  block  is  returned,  the  size  and  location  of 
the  block  must  be  recorded  so  further  cal  I stomal  I oc(  )won'tuseit, 
and  so  that  when  you  call  free( ) the  system  knows  how  much 
memory  to  release. 

The  way  all  this  is  implemented  can  vary  widely.  For  example, 
there's  nothing  to  prevent  primitives  for  memory  allocation  being 
implemented  in  the  processor.  If  you're  curious,  you  can  write  test 
programs  to  try  to  guess  the  way  your  malloc(  )is  implemented. 
You  can  also  read  the  library  source  code,  if  you  have  it  (the  GNU 
C sources  are  always  aval  I able). 

Early  examples  redesigned 

Using  new  and  delete  the  Stash  example  introduced  previously  in 
this  book  can  be  rewritten  using  all  the  features  discussed  in  the 
book  so  far.  Examining  the  new  code  will  also  give  you  a useful 
review  of  the  topics. 

At  this  poi  nt  i n the  book,  neither  the  Stash  nor  Stack  cl  asses  wi  1 1 
"own"  the  objects  they  point  to;  that  is,  when  the  Stash  or  Stack 
object  goes  out  of  scope,  it  will  not  cal  I deletefor  all  the  objects  it 
points  to.  The  reason  this  is  not  possible  is  because,  in  an  attempt  to 
be  generic,  they  hold  void  pointers.  If  you  deletea  void  pointer,  the 
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only  thing  that  happens  is  the  memory  gets  released,  because 
there's  no  type  information  and  no  way  for  the  compiler  to  know 
what  destructor  to  cal  I . 

delete  void^  is  probably  a bug 

It's  worth  making  a point  that  if  you  call  del  etefor  avoid*  it's 
almost  certainly  going  to  bea  bug  in  your  program  unless  the 
destination  of  that  pointer  is  very  simple;  in  particular,  it  should 
not  have  a destructor.  H ere's  an  example  to  show  you  what 
happens: 

// : C13 : BadVoidPointerDeletion . cpp 

//  Deleting  void  pointers  can  cause  memory  leaks 

#include  <iostream> 

using  namespace  std; 


class  Object  { 

void*  data;  //  Some  storage 
const  int  size; 
const  char  id; 
public : 

Object (int  sz,  char  c)  : size(sz),  id(c)  { 
data  = new  char[size]; 
cout  <<  "Constructing  object  " <<  id 
<<  ",  size  = " <<  size  <<  endl; 

} 

-Object ( ) { 

cout  <<  "Destructing  object  " <<  id  <<  endl; 
delete  []data;  //  OK,  just  releases  storage, 
//  no  destructor  calls  are  necessary 


}; 


int  main  ( ) { 

Object*  a = new  Object  (40,  'a'); 

delete  a; 

void*  b = new  Object (40,  'b'); 

delete  b; 

} ///:- 
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The  class  Objectcontai ns  a void* that  is  initialized  to  "raw"  data  (it 
doesn't  point  to  objects  that  have  destructors).  In  the  Object 
destructor,  del eteis  called  for  this  void*with  no  ill  effects,  since 
theonly  thing  we  need  to  happen  is  for  the  storage  to  be  released. 

H owever,  in  main(  )you  can  see  that  it's  very  necessary  that  delete 
know  what  type  of  object  it's  working  with.  Here's  the  output: 

Constructing  object  a,  size  = 40 
Destructing  object  a 
Constructing  object  b,  size  = 40 

Because  delete  aknows  that  a poi  nts  to  an  0 bject  the  destructor  is 
called  and  thus  the  storage  allocated  for  data  is  released.  However, 
if  you  manipulate  an  object  through  a void*as  in  thecaseof  delete 
b,  the  only  thi  ng  that  happens  is  that  the  storage  for  the  0 bjectis 
released  - but  the  destructor  is  not  cal  led  so  there  is  no  release  of 
the  memory  that  data  poi  nts  to.  When  this  program  compiles,  you 
probably  won't  see  any  warning  messages;  the  compiler  assumes 
you  know  what  you're  doing.  So  you  get  a very  quiet  memory  leak. 

If  you  have  a memory  leak  in  your  program,  search  through  all  the 
deletestatements  and  check  thetypeof  pointer  being  deleted.  If  it's 
avold*then  you've  probably  found  one  source  of  your  memory 
leak  (C++ provides  ample  other  opportunities  for  memory  leaks, 
however). 

Cleanup  responsibility  with  pointers 

To  make  the  Stash  and  Stack  containers  flexible  (able  to  hold  any 
type  of  object),  they  will  hold  void  pointers.  This  means  that  when 
a pointer  is  returned  from  the  Stash  or  Stack  object,  you  must  cast 
it  to  the  proper  type  before  using  it;  as  seen  above,  you  must  also 
cast  it  to  the  proper  type  before  deleting  it  or  you'll  get  a memory 
leak. 

The  other  memory  leak  issue  has  to  do  with  making  sure  that 
deleteis  actually  called  for  each  object  pointer  held  in  the 
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container.  The  container  cannot  "own"  the  pointer  because  it  holds 
it  as  a void*and  thus  cannot  perform  the  proper  cleanup.  The  user 
must  be  responsible  for  cleaning  up  the  objects.  This  produces  a 
serious  problem  if  you  add  pointers  to  objects  created  on  the  stack 
and  objects  created  on  the  heap  to  the  same  contai  ner  because  a 
delete-expression  is  unsafe  for  a pointer  that  hasn't  been  allocated 
on  the  heap.  (And  when  you  fetch  a pointer  back  from  the 
container,  how  will  you  know  where  its  object  has  been  allocated?) 
Thus,  you  must  be  sure  that  objects  stored  in  thefol  lowing  versions 
of  Stash  and  Stack  are  made  only  on  the  heap,  either  through 
careful  programming  or  by  creating  cl  asses  that  can  only  be  built 
on  the  heap. 

It's  also  important  to  make  sure  that  the  client  programmer  takes 
responsi  bi  I ity  for  cl  eani  ng  u p al  I the  poi  nters  i n the  contai  ner. 
You've  seen  in  previous  examples  how  the  Stack  cl  ass  checks  in  its 
destructor  that  all  the  Linkobjects  have  been  popped.  For  a Stash 
of  pointers,  however,  another  approach  is  needed. 

Stash  for  pointers 

This  new  version  of  the  Stash  class,  called  PStasK  holds  po/nters  to 
objects  that  exist  by  themselves  on  the  heap,  whereas  the  old  Stash 
in  earlier  chapters  copied  the  objects  by  value  into  the  Stash 
container.  Using  new  and  delete  it's  easy  and  safe  to  hold  pointers 
to  objects  that  have  been  created  on  the  heap. 

H ere's  the  header  fi  I e for  the " poi  nter  Stash" : 

//:  C13:PStash.h 

//  Holds  pointers  instead  of  objects 
#ifndef  PSTASH_H 
#define  PSTASH_H 

class  PStash  { 

int  quantity;  //  Number  of  storage  spaces 
int  next;  //  Next  empty  space 
//  Pointer  storage: 
void**  storage; 
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void  inflate  (int  increase); 
public : 

PStashO  : quantity  (0),  storage  (0),  next(O)  {} 

-PStash ( ) ; 

int  add (void*  element); 

void*  operator []  (int  index)  const;  //  Fetch 
//  Remove  the  reference  from  this  PStash: 
void*  remove (int  index); 

//  Number  of  elements  in  Stash: 
int  count  0 const  { return  next;  } 

}; 

#endif  //  PSTASH_H  ///:- 

Theun(derlying  data  elements  are  fairly  similar,  but  now  storageis 
an  array  of  void  pointers,  and  the  allocation  of  storage  for  that 
array  is  performed  with  new  instead  of  malloc( ) In  the  express!  on 

void**  St  = new  void* [quantity  + increase]; 

the  type  of  object  al  located  is  a void*  so  the  expression  al  locates  an 
array  of  void  poi  nters. 

The  destructor  deletes  the  storage  where  the  void  pointers  are  held 
rather  than  attempting  to  delete  what  they  point  at  (which,  as 
previously  noted,  will  release  their  storage  and  not  call  the 
destructors  because  a void  poi  nter  has  no  type  i nformation). 

The  other  change  is  the  replacement  of  thefetch(  )function  with 
operator[  ] which  makes  more  sense  syntactically.  Again,  however, 
a void*  is  returned,  so  the  user  must  remember  what  types  are 
stored  in  the  container  and  castthepointers  when  fetching  them 
out  (a  problem  that  will  be  repaired  in  future  chapters). 

Here  are  the  member  function  definitions: 

//:  C13 : PStash . cpp  {0} 

//  Pointer  Stash  definitions 
#include  "PStash. h" 

#include  ".. /require . h" 

#include  <iostream> 

#include  <cstring>  //  'mem'  functions 
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using  namespace  std; 


int  PStash :: add (void*  element)  { 
const  int  inflateSize  = 10; 
if (next  >=  quantity) 
inflate (inflateSize)  ; 
storage [next++]  = element; 
return (next  - 1);  //  Index  number 


//  No  ownership: 

PStash :: -PStash ( ) { 

for  (int  i = 0;  i < next;  i++) 
require ( storage [ i ] ==  0, 

"PStash  not  cleaned  up"); 
delete  [] storage; 

} 

//  Operator  overloading  replacement  for  fetch 

void*  PStash :: operator [ ] (int  index)  const  { 
require ( index  >=  0, 

"PStash :: operator [ ] index  negative"); 
if (index  >=  next) 

return  0;  //  To  indicate  the  end 
//  Produce  pointer  to  desired  element: 
return  storage [ index] ; 

} 

void*  PStash :: remove ( int  index)  { 
void*  V = operator [] (index); 

//  "Remove"  the  pointer: 

if (v  !=  0)  storage [ index]  = 0; 

return  v; 


void  PStash :: inf late ( int  increase)  { 
const  int  psz  = sizeof (void* ) ; 
void**  St  = new  void* [quantity  + increase]; 
memset (st,  0,  (quantity  + increase)  * psz); 
memcpy(st,  storage,  quantity  * psz); 
quantity  +=  increase; 
delete  [] storage;  //  Old  storage 
storage  = st;  //  Point  to  new  memory 
} ///:- 
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Theadd(  )function  iseffectively  the  same  as  before,  except  thata 
pointer  is  stored  instead  of  a copy  of  the  whole  object. 

The  inflate!  )code  is  modified  to  handle  the  allocation  of  an  array 
of  void*  instead  of  the  previous  design,  which  was  only  working 
with  raw  bytes.  H ere,  instead  of  using  the  prior  approach  of 
copying  by  array  indexing,  the  Standard  C library  function 
memset(  )i  s f i rst  used  to  set  al  I the  new  memory  to  zero  (thi  s i s not 
strictly  necessary,  sincethePStashis  presumably  managing  all  the 
memory  correctly  - but  it  usually  doesn't  hurt  to  throw  in  a bit  of 
extra  care).  Then  memcpy(  )moves  the  existing  data  from  the  old 
location  to  the  new.  Often,  functions  like  memset(  )and  memcpy( ) 
have  been  opti  mi  zed  over  ti  me,  so  they  may  be  faster  than  the 
loops  shown  previously.  But  with  a function  I ike  inflate!  )that  will 
probably  not  be  used  that  often  you  may  not  see  a performance 
difference.  However,  the  fact  that  the  function  cal  Is  are  more 
concise  than  the  loops  may  help  prevent  coding  errors. 

To  put  the  responsibility  of  object  cleanup  squarely  on  the 
shou  I ders  of  the  cl  i ent  programmer,  there  are  two  ways  to  access 
the  pointers  in  the  PStash:  the  operator!]  which  simply  returns  the 
pointer  but  leaves  it  as  a member  of  the  container,  and  a second 
member  function  remove! ) which  returns  the  pointer  but  also 
removes  it  from  the  container  by  assigning  that  position  to  zero. 
When  the  destructor  for  PStashiscalled,  it  checks  to  make  sure 
that  all  object  pointers  have  been  removed;  if  not,  you're  notified  so 
you  can  preventa  memory  leak  (moreelegant  solutions  will  be 
forthcoming  in  later  chapters). 

A test 

H ere's  the  old  test  program  for  Stash  rewritten  for  the  PStash 

//:  C13 : PStashTest . cpp 
//{L}  PStash 

//  Test  of  pointer  Stash 
#include  "PStash. h" 

#include  ".. /require . h" 

#include  <iostream> 
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#include  <fstream> 

#include  <string> 
using  namespace  std; 

int  main  ( ) { 

PStash  intStash; 

//  'new'  works  with  built-in  types,  too.  Note 
//  the  "pseudo-constructor"  syntax: 
for(int  i = 0;  i < 25;  i++) 
intStash . add (new  int (i) ) ; 
for  (int  j = 0;  j < intStash . count () ; j++) 

cout  <<  "intStash ["  <<  j <<  "]  = " 

<<  *( int *) intStash [ j ] <<  endl; 

//  Clean  up: 

for  (int  k = 0;  k < intStash . count () ; k++) 
delete  intStash . remove (k) ; 
ifstream  in  ( "PStashTest . cpp" ) ; 
assure  (in,  "PStashTest . cpp" ) ; 

PStash  stringStash; 
string  line; 

while (getline (in,  line)) 

stringStash . add (new  string(line) ) ; 

//  Print  out  the  strings: 

for  (int  u = 0;  stringStash [u] ; u++) 

cout  <<  " stringStash [ " <<  u <<  "]  = " 

<<  * (string*) stringStash [u]  <<  endl; 

//  Clean  up: 

for  (int  V = 0;  v < stringStash . count () ; v++) 
delete  (string* ) stringStash . remove (v) ; 

} ///:- 

As  before,  Stashes  are  created  and  filled  with  infornnation,  but  this 
ti  me  the  i nformati  on  i s the  poi  nters  resu  I ti  ng  from  new- 
expressions.  In  the  first  case,  note  the  line: 

intStash . add (new  int  (i) ) ; 

The  expression  new  int(i)usesthe  pseudo-constructor  form,  so 
storagefor  a new  int  object  is  created  on  the  heap,  and  the  int  is 
initialized  tothevaluei. 

During  printing,  the  value  returned  by  PStash  ::operator[  Jnust  be 
cast  to  the  proper  type;  this  is  repeated  for  the  rest  of  the  PStash 
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objects  in  the  program.  It'san  undesirableeffectof  using  void 
pointers  as  the  underlying  representation  and  will  be  fixed  in  later 
chapters. 

The  second  test  opens  the  source  code fi  le  and  reads  it  one  I i ne  at  a 
ti  me  i nto  another  PStasK  Each  I i ne  i s read  i nto  a stri  ng  usi  ng 
getl  i ne( ) then  a new  stri  ng  i s created  from  i i neto  make  an 
independent  copy  of  that  line.  If  wejust  passed  in  the  address  of 
i i neeach  ti  me,  we'd  get  a whol e bu  nch  of  poi  nters  poi  nti  ng  to  i i ne 
which  would  only  contain  the  last  line  that  was  read  from  the  file. 

When  fetching  the  pointers,  you  seethe  expression: 

* (string*) stringStash [ v] 

The  pointer  returned  from  operator[  ]must  be  cast  to  a string*to 
give  it  the  proper  type.  Then  the  string*  is  dereferenced  so  the 
expression  evaluates  to  an  object,  at  which  point  the  compiler  sees  a 
string  object  to  send  to  cout 

The  objects  created  on  the  heap  must  be  destroyed  through  the  use 
of  the  remove(  )statement  or  else  you 'I  I get  a message  at  runti  me 
telling  you  that  you  haven't  completely  cleaned  up  the  objects  in 
the  PStasK  N oti  ce  that  i n the  case  of  the  i nt  poi  nters,  no  cast  i s 
necessary  because  there's  no  destructor  for  an  intand  all  we  need  is 
memory  release: 

delete  intStash . remove (k) ; 

H owever,  for  the  string  poi  nters,  if  you  forget  to  do  the  cast  you'l  I 
have  another  (quiet)  memory  leak,  so  the  cast  is  essential: 

delete  (string*) stringStash. remove (k) ; 

Some  of  these  issues  (but  not  all)  can  be  removed  using  templates 
(which  you'll  learn  about  in  Chapter  16). 
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new  & delete  for  arrays 

I n C++,  you  can  create  arrays  of  objects  on  the  stack  or  on  the  heap 
with  equal  ease,  and  (of  course)  the  constructor  is  called  for  each 
object  i n the  array.  There's  one  constrai  nt,  however:  There  must  be 
a default  constructor,  except  for  aggregate  initialization  on  the 
stack  (see  Chapter  6),  because  a constructor  with  no  arguments 
must  be  called  for  every  object. 

When  creating  arrays  of  objects  on  the  heap  using  new,  there's 
something  else  you  must  do.  An  example  of  such  an  array  is 

I MyType*  fp  = new  MyType[100]; 

Thi  s al  I ocates  enough  storage  on  the  heap  for  100  M yTypeobjects 
and  cal  Is  the  constructor  for  each  one.  Now,  however,  you  simply 
have  a MyType*  which  is  exactly  the  same  as  you'd  get  if  you  said 

I MyType*  fp2  = new  MyType; 

to  create  a si  ngle  object.  Because  you  wrote  the  code,  you  know  that 
fp  is  actually  the  starting  address  of  an  array,  so  it  makes  sense  to 
select  array  elements  using  an  expression  likefp[31  But  what 
happens  when  you  destroy  the  array?  The  statements 

delete  fp2;  //  OK 

delete  fp;  //  Not  the  desired  effect 

I ook  exacti  y the  same,  and  thei  r effect  will  be  the  same.  The 
destructor  will  be  cal  led  fortheMyTypeobject  pointed  to  by  the 
given  address,  and  then  the  storage  will  be  released.  Forfp2this  is 
fi  ne,  but  for  fp  this  means  that  the  other  99  destructor  calls  won't  be 
made.  The  proper  amount  of  storage  will  still  be  released,  however, 
because  it  is  allocated  in  one  big  chunk,  and  the  size  of  the  whole 
chunk  is  stashed  somewhere  by  the  allocation  routine. 

The  solution  requires  you  to  givethe compiler  the  information  that 
this  is  actually  the  starting  address  of  an  array.  This  is 
accomplished  with  the  following  syntax: 
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delete  [ ] fp; 


The  empty  brackets  tell  the  compiler  to  generate  code  that  fetches 
the  number  of  objects  in  the  array,  stored  somewhere  when  the 
array  is  created,  and  cal  Is  the  destructor  for  that  many  array 
objects.  This  is  actually  an  improved  syntax  from  the  earlier  form, 
which  you  may  still  occasionally  see  in  old  code: 

I delete  [ 100 ] fp; 

which  forced  the  programmer  to  includethenumber  of  objects  in 
the  array  and  introduced  the  possibility  that  the  programmer 
would  get  it  wrong.  The  additional  overhead  of  letting  the  compiler 
handleit  was  very  low,  and  it  was  considered  better  to  specify  the 
number  of  objects  in  one  place  instead  of  two. 

Making  a pointer  more  iike  an  array 

Asan  aside,  thefp  defined  above  can  be  changed  to  point  to 
anything,  which  doesn't  make  sense  for  the  starting  address  of  an 
array.  It  makes  more  sense  to  define  it  as  a constant,  so  any  attempt 
to  modify  the  pointer  will  be  flagged  asan  error.  To  get  this  effect, 
you  might  try 

I int  const*  q = new  int[10]; 

or 

I const  int*  q = new  int [10]; 

but  i n both  cases  the  const w i 1 1 bi  nd  to  the  i nt  that  i s,  w hat  i s bei  ng 
pointed  to,  rather  than  thequality  of  the  pointer  itself.  Instead,  you 
must  say 

I int*  const  q = new  int [10]; 

Now  the  array  elements  in  q can  be  modified,  but  any  change  to  q 
(likeq++)  is  illegal,  as  it  is  with  an  ordinary  array  identifier. 
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Running  out  of  storage 

What  happens  when  the  operator  newcannotfind  a contiguous 
block  of  storage  large  enough  to  hold  the  desired  object?  A special 
function  called  the  new-handier  is  called.  Or  rather,  a pointer  to  a 
function  is  checked,  and  if  the  pointer  is  nonzero,  then  the  function 
it  points  to  iscalled. 

The  default  behavior  for  the  new-handier  is  to  throw  an  exception,  a 
subject  covered  in  Volume  2.  However,  if  you're  using  heap 
allocation  in  your  program,  it's  wise  to  at  least  replacethe  new- 
handier  with  a message  that  says  you've  run  out  of  memory  and 
then  abortstheprogram.  That  way,  during  debugging,  you'll  have 
a clue  about  what  happened.  For  the  final  program  you'll  want  to 
use  more  robust  recovery. 

You  replacethe  new-handier  by  including  new  .hand  then  calling 
set_new_handler(  Kith  the  address  of  the  function  you  want 
installed: 

//:  C13 : NewHandler . cpp 
//  Changing  the  new-handier 
#include  <iostream> 

#include  <cstdlib> 

#include  <new> 
using  namespace  std; 

int  count  = 0; 

void  out_of_memory ( ) { 

cerr  <<  "memory  exhausted  after  " <<  count 
<<  " allocations!"  <<  endl; 
exit ( 1 ) ; 

} 

int  main  ( ) { 

set_new_handler (out_of_memory) ; 
while  ( 1 ) { 

countt+; 

new  int [1000];  //  Exhausts  memory 

} 
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} III-.- 

The  new-handier  function  must  take  no  arguments  and  have  a void 
return  value.  The  whileloop  will  keep  allocating  int objects  (and 
throwing  away  their  return  addresses)  until  the  free  store  is 
exhausted.  At  the  very  next  cal  I to  new,  no  storage  can  be  al  located, 
so  the  new-handier  will  be  called. 

Thebehavior  of  the  new-handier  is  tied  to  operator  newfso  if  you 
overload  operator  new(covered  in  the  next  section)  the  new- 
handier  will  not  be  called  by  default.  If  you  still  want  the  new- 
handier  to  be  called  you'll  have  to  write  the  code  to  do  so  inside 
your  overloaded  operator  new 

Of  course,  you  can  write  more  sophisticated  new-handlers,  even 
one  to  try  to  reclaim  memory  (commonly  known  as  a garbage 
collector).  This  is  not  a job  for  the  novice  programmer. 


Overloading  new  & delete 

When  you  createa  new-expression,  two  things  occur.  First,  storage 
i s al  I ocated  usi  ng  the  operator  nevv  then  the  constructor  i s cal  I ed . 
In  a delete-expression,  the  destructor  is  cal  led,  then  storage  is 
deallocated  using  the  operator  del  eteThe  constructor  and 
destructor  cal  Is  are  never  under  your  control  (otherwise  you  might 
accidentally  subvert  them),  but  you  can  change  the  storage 
allocation  functions  operator  newand  operator  delete 

The  memory  allocation  system  used  by  newand  del  eteis  designed 
for  general-purpose  use.  In  special  situations,  however,  it  doesn't 
serve  your  needs.  The  most  common  reason  to  change  the  allocator 
is  efficiency:  You  might  be  creating  and  destroying  so  many  objects 
of  a particular  cl  ass  that  it  has  become  a speed  bottleneck.  C-h- 
allowsyou  to  overload  newand  deleteto  implement  your  own 
storage  allocation  scheme,  so  you  can  handle  problems  I ike  this. 
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Another  issue  is  heap  fragmentation.  By  allocating  objects  of 
different  sizes  it's  possible  to  break  up  the  heap  so  that  you 
effectively  run  out  of  storage.  That  is,  the  storage  might  be 
available,  but  because  of  fragmentation  no  piece  is  big  enough  to 
satisfy  your  needs.  By  creating  your  own  allocator  for  a particular 
class,  you  can  ensure  this  never  happens. 

In  embedded  and  real-time  systems,  a program  may  haveto  run  for 
a very  long  time  with  restricted  resources.  Such  a system  may  also 
requ  i re  that  memory  al  I ocati  on  al  ways  take  the  same  amou  nt  of 
time,  and  there's  no  allowance  for  heap  exhaustion  or 
fragmentation.  A custom  memory  allocator  is  the  solution; 
otherwise,  programmers  will  avoid  using  new  and  delete 
altogether  in  such  cases  and  miss  out  on  a valuable  C-h- asset. 

When  you  overload  operator  newand  operator  deleteit's 

important  to  remember  that  you're  changing  only  the  way  raw 
storage  is  allocated. ThecompWer  \N\W  simply  call  your  new  instead 
of  the  default  version  to  allocate  storage,  then  call  the  constructor 
for  that  storage.  So,  although  the  compiler  allocates  storage  and 
cal  Is  the  constructor  when  it  sees  new,  all  you  can  change  when 
you  overload  new  is  the  storage  all  ocati  on  portion,  (deletehasa 
similar  limitation.) 

When  you  overload  operatornew,  you  also  replace  the  behavior 
when  it  runs  out  of  memory,  so  you  must  decide  what  to  do  in 
your  operator  new  return  zero,  write  a loop  to  call  the  new- 
handier  and  retry  allocation,  or  (typically)  throw  abad_alloc 
exception  (discussed  in  Volume 2,  availableat  www.BruceEckel.com}. 

Overloading  new  and  del  eteis  I ike  overloading  any  other  operator. 
However,  you  havea  choice  of  overloading  the  global  allocator  or 
u si  n g a d i fferent  al  I ocator  for  a parti  cu  I ar  cl  ass. 
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Overloading  global  new  & delete 

This  is  the  drastic  approach,  when  thegiobai  versions  of  new  and 
del eteare  unsatisfactory  for  the  whoie  system,  if  you  overioad  the 
giobai  versions,  you  makethedefauitscompieteiy  inaccessibie- 
you  can't  even  caii  them  from  insideyour  redefinitions. 

Theoverioaded  new  musttakean  argument  of  si ze_t(the Standard 
C standard  typefor  sizes).  This  argument  is  generated  and  passed 
to  you  by  thecompiier  and  is  the  size  of  the  object  you 're 
responsibiefor  aiiocating.  You  must  return  a pointer  either  to  an 
object  of  that  size  (or  bigger,  if  you  have  some  reason  to  do  so),  or 
to  zero  if  you  can't  find  the  memory  (in  which  case  the  constructor 
is  not  caii ed!).  However,  if  you  can't  find  the  memory,  you  shouid 
probabiy  do  something  more  informative  than  just  returning  zero, 
i i ke  cai  i i ng  the  new-hand i er  or  th row i ng  an  except! on,  to  si gnai 
that  there's  a probiem. 

The  return  vaiue  of  operator  newisavoid*  not  a pointer  to  any 
particuiar  type.  Aii  you'vedone  is  produce  memory,  not  a finished 
object-  that  doesn't  happen  untii  the  constructor  iscaiied,  an  act 
thecompiier  guarantees  and  which  isoutof  your  controi. 

The  operator  deletetakes  a void* to  memory  that  was  aiiocated  by 

operator  new  it's  a void*  because  operator  deleteoniy  gets  the 
pointer  after  thedestructor  iscaiied,  which  removes  the  object-ness 
from  the  piece  of  storage.  The  return  type  is  void. 

H ere's  a si mpieexampie showing  how  to  overioad  thegiobai  new 

and  delete 

//:  C13 : GlobalOperatorNew . cpp 
//  Overload  global  new/delete 
#include  <cstdio> 

#include  <cstdlib> 
using  namespace  std; 

void*  operator  new(size_t  sz)  { 

print! ( "operator  new:  %d  Bytes\n",  sz); 
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void*  m = malloc(sz); 
if(!m)  puts ("out  of  memory"); 
return  m; 

} 

void  operator  delete (void*  m)  { 
puts ( "operator  delete"); 
free (m) ; 


class  S { 
int  i [ 100 ] ; 
public : 

SO  { puts  ("S:  :S  0 ")  ; } 

~S  0 { puts  ("S:  :~S  0 ") ; } 


int  main  ( ) { 

puts ( "creating  & destroying  an  int"); 
int*  p = new  int  (47); 
delete  p; 

puts ( "creating  & destroying  an  s"); 

S*  s = new  S; 
delete  s; 

puts ( "creating  & destroying  S[3]"); 

S*  sa  = new  S [ 3 ] ; 
delete  [ ] sa; 

} ///:- 

Here  you  can  see  the  general  form  for  overloading  new  and  delete 
These  use  the  Standard  C library  functions  mall  oc(  )and  free(  )for 
the  allocators  (which  is  probably  what  the  default  new  and  delete 
use  as  well!).  However,  they  also  print  messages  about  what  they 
are  doing.  Noticethatprintf(  )and  puts(  )areused  rather  than 
lostreamsThis  is  because  when  an  I ostream  object  is  created  (like 
the  global  cin,  cout  and  cerr),  it  calls  new  to  allocate  memory.  With 
prlntf( ) you  don't  get  into  a deadlock  because  it  doesn't  call  new 
to  initialize  itself. 

In  main( ) objects  of  built-in  types  are  created  to  prove  that  the 
overloaded  new  and  deletearealso  called  in  that  case.  Then  a 
single  object  of  types  is  created,  followed  by  an  array  of  S.  For  the 
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array,  you'll  see  from  the  number  of  bytes  requested  that  extra 
memory  I sal  located  to  store  information  (inside  the  array)  about 
the  number  of  objects  it  holds.  In  all  cases,  the  global  overloaded 
versions  of  new  and  deleteare  used. 

Overloading  new  & delete  for  a class 

Although  you  don't  haveto  explicitly  say  static  when  you 
overload  new  and  deletefor  a class,  you're  creating  staticmember 
f u net!  ons.  A s before,  the  syntax  I s the  same  as  overl  oad  I ng  any 
other  operator.  When  the  compi  ler  sees  you  use  new  to  create  an 
object  of  your  class,  it  chooses  the  member  operator  newover  the 
global  version.  However,  the  global  versions  of  new  and  deleteare 
used  for  all  other  types  of  objects  (unless  they  have  their  own  new 
and  delete. 

In  the  foil  owing  example,  a primitive  storage  allocation  system  is 
created  for  the  class  Framis  A chunk  of  memory  is  set  aside  in  the 
static  data  area  at  program  start-up,  and  that  memory  is  used  to 
allocate  space  for  objectsof  type  Framis  To  determine  which 
blocks  have  been  allocated,  a simple  array  of  bytes  is  used,  one  byte 
for  each  block: 

//:  C13 : Framis . epp 
//  Local  overloaded  new  & delete 
#include  <cstddef>  //  Size_t 
#include  <fstream> 

#include  <iostream> 

#include  <new> 

using  namespace  std; 

of stream  out ( "Framis . out ")  ; 

class  Framis  { 

enum  { sz  = 10  } ; 

char  c[sz];  //  To  take  up  space,  not  used 
static  unsigned  char  pool[]; 
static  bool  alloc_map[]; 
public : 

enum  { psize  = 100  };  //  frami  allowed 

Framis 0 { out  <<  "Framis () \n" ; } 
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~Framis()  { out  <<  "~Framis()  ...  } 

void*  operator  new(size_t)  throw (bad_alloc) ; 
void  operator  delete (void* ) ; 

}; 

unsigned  char  Framis : : pool [psize  * sizeof (Framis ) ] ; 
bool  Framis :: alloc_map [psize]  = {false}; 

//  Size  is  ignored  — assume  a Framis  object 
void* 

Framis :: operator  new(size_t)  throw (bad_alloc)  { 
for(int  i = 0;  i < psize;  it+) 
if ( ! alloc_map [ i ] ) { 

out  <<  "using  block  " <<  i <<  " ...  "; 

alloc_map[i]  = true;  //  Mark  it  used 
return  pool  + (i  * sizeof (Framis )) ; 

} 

out  <<  "out  of  memory"  <<  endl; 
throw  bad_alloc(); 

} 

void  Framis :: operator  delete (void*  m)  { 
if(!m)  return;  //  Check  for  null  pointer 
//  Assume  it  was  created  in  the  pool 
//  Calculate  which  block  number  it  is: 
unsigned  long  block  = (unsigned  long)m 
- (unsigned  long) pool; 
block  /=  sizeof (Framis ) ; 

out  <<  "freeing  block  " <<  block  <<  endl; 

//  Mark  it  free: 
alloc_map [block]  = false; 

} 

int  main  ( ) { 

Framis*  f [Framis : :psize] ; 
try  { 

for(int  i = 0;  i < Framis :: psize;  itt) 
f[i]  = new  Framis; 
new  Framis;  //  Out  of  memory 
} catch (bad_alloc)  { 

cerr  <<  "Out  of  memory!"  <<  endl; 

} 

delete  f [ 10 ] ; 
f[10]  = 0; 

//  Use  released  memory: 

Framis*  x = new  Framis; 
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delete  x; 

for(int  j = 0;  j < Framis : : psize;  j++) 
delete  f[j];  //  Delete  f[10]  OK 
} III-.- 

The  pool  of  memory  for  the Framisheap  iscreated  by  allocating  an 
array  of  bytes  large  enough  to  hold  psizeFramisobjects.  The 
allocation  map  is  psizeelements  long,  so  there's  one  bool  for  every 
bl  ock.  A 1 1 the  val  u es  i n the  al  I ocati  on  map  are  i n i ti  al  i zed  to  f al se 
usi  ng  the  aggregate  i ni  ti  al  i zati  on  tri  ck  of  sett!  ng  the  f i rst  el  ement  so 
the  compi  ler  automatical  I y i nitial  izes  al  I the  rest  to  the!  r normal 
default  value  (which  is  falsa  in  the  case  of  bool). 

The  local  operator  newhas  the  same  syntax  as  the  global  one.  All  it 
doesissearch  through  the  allocation  map  looking  for  a false  value, 
then  sets  that  location  to  trueto  indicate  it's  been  allocated  and 
returns  the  address  of  the  corresponding  memory  block.  If  it  can't 
fi  nd  any  memory,  it  issues  a message  to  the  trace  fi  le  and  throws  a 
bad_al  I ocexcepti  on . 

This  isthefirst  example  of  exceptions  that  you've  seen  in  this  book. 
Si  nee  detailed  discussion  of  exceptions  is  delayed  until  Volume  2, 
this  Isa  very  simple  use  of  them.  In  operator  newtherearetwo 
artifacts  of  exception  handling.  First,  the  function  argument  list  is 
followed  by  throw(bad_allocjwhich  tel  Is  the  compi  ler  and  the 
reader  that  this  function  may  throw  an  exception  of  typebad_alloc 
Second,  if  there's  no  more  memory  the  function  actually  does 
throw  the  exception  in  the  statement  throw  bad_allocWhen  an 
exception  isthrown,  the  function  stops  executi  ng  and  control  is 
passed  to  an  exception  handler,  which  is  expressed  as  a catch  clause. 

In  maln( ) you  see  the  other  part  of  the  picture,  which  is  the  try- 
catch  clause.  Thetry  block  is  surrounded  by  braces  and  contains  all 
the  code  that  may  throw  exceptions  - in  this  case,  any  cal  I to  new 
that  involves  Framisobjects.  Immediately  following  thetry  block  is 
one  or  more  catch  clauses,  each  one  specifying  the  type  of 
exception  that  they  catch.  I n this  case,  catch(bad_alloc]Eays  that 
that  bad_allocexceptions  will  be  caught  here.  This  particular  catch 
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clause  is  only  executed  when  abad_allocexception  isthrown,  and 
execution  continues  after  the  end  of  the  last  catch  clause  in  the 
group  (there's  only  one  here,  but  there  could  be  more). 

In  this  example,  it's  OK  to  useiostreams  because  the  global 

operator  newand  deleteare  untouched. 

The  operator  deleteassumes  the  Framisaddress  was  created  in  the 
pool.  This  is  a fair  assumption,  because  the  local  operator  newwi  1 1 
be  called  whenever  you  create  a single  Framisobject  on  the  heap  - 
but  not  an  array  of  them:  global  new  is  used  for  arrays.  So  the  user 
might  accidentally  havecalled  operator  deletewithout  using  the 
empty  bracket  syntax  to  indicatearray  destruction.  This  would 
cause  a problem.  Also,  the  user  might  be  deleting  a pointer  to  an 
object  created  on  the  stack.  If  you  think  these  things  could  occur, 
you  might  want  to  add  a line  to  make  sure  the  address  is  within  the 
pool  and  on  a correct  boundary  (you  may  also  begin  to  seethe 
potential  of  overloaded  new  and  deletefor  finding  memory  leaks). 

operator  delete:alculates  the  block  in  the  pool  that  this  pointer 
represents,  and  then  sets  the  allocation  map's  flag  for  that  block  to 
fal  se  to  I nd  I cate  the  bl  ock  has  been  rel  eased . 

In  main( ) enough  Framisobjects  are  dynamically  allocated  to  run 
out  of  memory;  this  checks  the  out-of-memory  behavior.  Then  one 
of  the  objects  is  freed,  and  another  one  is  created  to  show  that  the 
released  memory  is  reused. 

Because  this  allocation  scheme  is  specific  to  Framisobjects,  it's 
probably  much  faster  than  the  general -purpose  memory  allocation 
scheme  used  for  the  default  new  and  delete  However,  you  should 
note  that  it  doesn't  automatically  work  if  inheritance  is  used 
(inheritance  is  covered  in  Chapter  14). 
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Overloading  new  & delete  for  arrays 

If  you  overload  operator  new  and  deletefor  a class,  those  operators 
are  cal  led  whenever  you  create  an  object  of  that  class.  However,  if 
you  create  an  array  of  those  class  objects,  the  global  operatornew  is 
called  to  allocate  enough  storage  for  the  array  all  at  once,  and  the 
global  operatordeleteis  called  to  release  that  storage.  You  can 
control  the  allocation  of  arrays  of  objects  by  overloading  the  special 
array  versions  of  operator  new[  fend  operator  delete[  Jor  the 
class.  Here'san  examplethat  shows  when  the  two  different 
versions  are  cal  led: 


//:  C13 :ArrayOperatorNew. cpp 
//  Operator  new  for  arrays 
#include  <new>  //  Size_t  definition 
#include  <fstream> 
using  namespace  std; 

of stream  trace ( "ArrayOperatorNew . out " ) ; 

class  Widget  { 

enum  { sz  = 10  } ; 

int  i [ sz ] ; 
public : 

Widget  0 { trace  <<  } 

-Widget  0 { trace  <<  } 

void*  operator  new(size_t  sz)  { 
trace  <<  "Widget :: new : " 

<<  sz  <<  " bytes"  <<  endl; 
return  : : new  char[sz]; 

} 

void  operator  delete (void*  p)  { 

trace  <<  "Widget :: delete " <<  endl; 

: : delete  [ ] p; 

} 

void*  operator  new [ ] (size_t  sz)  { 
trace  <<  "Widget: : new [ ] : " 

<<  sz  <<  " bytes"  <<  endl; 
return  : : new  char[sz]; 

} 

void  operator  delete [] (void*  p)  { 

trace  <<  "Widget :: delete [] " <<  endl; 
: : delete  [ ] p; 

} 
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trace  <<  "new  Widget"  <<  endl; 

Widget*  w = new  Widget; 

trace  <<  "\ndelete  Widget"  <<  endl; 

delete  w; 

trace  <<  "\nnew  Widget [25]"  <<  endl; 

Widget*  wa  = new  Widget [25]; 

trace  <<  "\ndelete  [] Widget"  <<  endl; 

delete  []wa; 

} ///:- 

Here,  the  global  versionsof  new  and  deletearecalled  so  the  effect 
is  the  same  as  having  no  overloaded  versionsof  new  and  delete 
except  that  trace  information  isadded.  Of  course,  you  can  use  any 
memory  allocation  scheme  you  want  in  the  overloaded  new  and 

delete 

Y ou  can  see  that  the  syntax  of  array  new  and  deleteis  the  same  as 
for  the  individual  object  versions  except  for  the  addition  of  the 
brackets.  I n both  cases  you're  handed  the  size  of  the  memory  you 
must  allocate.  The  size  handed  to  the  array  version  will  be  the  size 
of  the  entire  array.  It'sworth  keeping  in  mind  that  the  on/y  thing 
the  overloaded  operator  new  is  required  to  do  is  hand  back  a 
pointer  to  a large  enough  memory  block.  Although  you  may 
perform  initialization  on  that  memory,  normally  that's  the  job  of 
theconstructor  that  will  automatically  be  cal  led  for  your  memory 
by  the  compiler. 

The  constructor  and  destructor  si  mply  pri  nt  out  characters  so  you 
can  see  when  they've  been  called.  Here's  what  the  tracefile  looks 
I ike  for  one  compiler: 

new  Widget 

Widget: :new:  40  bytes 

:*r 

delete  Widget 
-Widget: : delete 
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new  Widget [25] 

Widget :: new [] : 1004  bytes 

■k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k 

delete  [] Widget 

Widget : : delete [ ] 

Creating  an  individual  object  requires  40  bytes,  as  you  might 
expect.  (This  machine  uses  four  bytes  for  an  int)  The  operator  new 
is  called,  then  the  constructor  (indicated  by  the*).  In  a 
complementary  fashion,  calling  deletecauses  the  destructor  to  be 
called,  then  the  operator  delete 

When  an  array  of  Widgetobjects  is  created,  the  array  version  of 
operator  newis  used,  as  promised.  But  notice  that  the  size 
requested  is  four  more  bytes  than  expected.  This  extra  four  bytes  is 
where  the  system  keeps  information  about  the  array,  in  particular, 
the  number  of  objects  in  the  array.  That  way,  when  you  say 

I delete  [] Widget; 

the  brackets  tel  I the  compi  I er  i t's  an  array  of  objects,  so  the  compi  I er 
generates  code  to  I ook  for  the  nu  mber  of  objects  i n the  array  and  to 
call  the  destructor  that  many  times.  You  can  see  that,  even  though 
the  array  operator  newand  operator  deleteare  only  cal  led  once  for 
the  enti  re  array  chunk,  the  default  constructor  and  destructor  are 
called  for  each  object  in  the  array. 

Constructor  calls 

Considering  that 

I MyType*  f = new  MyType; 

callsnewto allocatea MyTypesized  pieceof  storage, then  invokes 
the  M yTypeconstructor  on  that  storage,  what  happens  if  the 
storage  allocation  in  new  fails?  The  constructor  is  not  cal  led  in  that 
case,  so  although  you  still  have  an  unsuccessfully  created  object,  at 
least  you  haven't  invoked  the  constructor  and  handed  it  a zero  this 
pointer.  Here's  an  example  to  prove  it: 
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//:  C13 : NoMemory . cpp 

//  Constructor  isn't  called  if  new  fails 
#include  <iostreain> 

#include  <new>  //  bad_alloc  definition 
using  namespace  std; 

class  NoMemory  { 
public : 

NoMemory ( ) { 

cout  <<  "NoMemory :: NoMemory 0 " <<  endl; 

} 

void*  operator  new(size_t  sz)  throw (bad_alloc) { 
cout  <<  "NoMemory :: operator  new"  <<  endl; 
throw  bad_alloc();  //  "Out  of  memory" 


}; 


int  main  ( ) { 

NoMemory*  nm  = 0; 
try  { 

nm  = new  NoMemory; 

} catch (bad_alloc)  { 

cerr  <<  "Out  of  memory  exception"  <<  endl; 

} 

cout  <<  "nm  = " <<  nm  <<  endl; 

} ///:- 

When  the  program  runs,  it  does  not  print  the  constructor  message, 
only  the  message  from  operator  newand  the  message  in  the 
exception  handler.  Because  new  never  returns,  the  constructor  is 
never  called  so  its  message  is  not  printed. 

It's  important  that  nm  be  initialized  to  zero  because  the  new 
expression  never  completes,  and  the  pointer  should  be  zero  to 
make  sure  you  don't  misuse  it.  However,  you  should  actually  do 
more  in  the  except! on  handler  than  just  print  out  a message  and 
continue  on  as  if  the  object  had  been  successfully  created.  Ideally, 
you  will  do  something  that  will  cause  the  program  to  recover  from 
the  problem,  or  at  the  least  exit  after  logging  an  error. 

In  earlier  versions  of  C++ it  was  standard  practice  to  return  zero 
from  new  if  storage  allocation  failed.  That  would  prevent 
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construction  from  occurring.  H owever,  if  you  try  to  return  zero 
from  new  with  a Standard-conforming  compiler,  it  should  tell  you 
that  you  ought  to  throw  bad_allocinstead. 

placement  new  & delete 

There  are  two  other,  less  common,  uses  for  overloading  operator 
new. 

1.  You  may  want  to  place  an  object  in  a specific  location  in 
memory.  This  is  especially  important  with  hardware-oriented 
embedded  systems  where  an  object  may  be  synonymous 
with  a particular  piece  of  hardware. 

2 . You  may  want  to  be  abl  e to  choose  from  d ifferent  al  I ocators 
when  calling  new. 

Both  of  these  situations  are  solved  with  the  same  mechanism:  The 
overloaded  operator  newcan  take  more  than  one  argument.  As 
you've  seen  before,  thefi  rst  argument  is  always  the  size  of  the 
object,  which  is  secretly  calculated  and  passed  by  the  compiler.  But 
the  other  arguments  can  be  anything  you  want  - the  ad  dress  you 
want  the  object  placed  at,  a reference  to  a memory  allocation 
function  or  object,  or  anything  else  that  is  convenient  for  you. 

The  way  that  you  pass  the  extra  arguments  to  operator  newduring 
acall  may  seem  slightly  curious  at  first.  You  put  the  argument  list 
(w/t/iotyt  the  size_targument,  which  ishandled  by  the  compiler) 
after  the  keyword  new  and  before  the  cl  ass  name  of  the  object 
you're  creating.  For  example, 

I X*  xp  = new  (a)  X; 

will  pass  a as  the  second  argument  to  operator  newOf  course,  this 
can  work  only  if  such  an  operator  newhas  been  declared. 

Here's  an  example  showing  how  you  can  pi  ace  an  object  at  a 
particular  location: 


13:  Dynamic  Object  Creation 


607 


//:  C13 : PlacementOperatorNew . cpp 
//  Placement  with  operator  new 
#include  <cstddef>  //  Size_t 
#include  <iostream> 
using  namespace  std; 

class  X { 
int  i ; 
public : 

X ( int  ii  = 0)  : i(ii)  { 

cout  <<  "this  = " <<  this  <<  endl; 

} 

~X()  { 

cout  <<  "X: : ~X ( ) : " <<  this  <<  endl; 

} 

void*  operator  new(size_t,  void*  loc)  { 
return  loc; 


}; 


int  main  ( ) { 

int  1[10]; 

cout  <<  "1  = " <<  1 <<  endl; 

X*  xp  = new(l)  X(47);  //  X at  location  1 

xp->X::~X();  //  Explicit  destructor  call 

//  ONLY  use  with  placement! 

} ///:- 

Notice  that  operator  newonly  returns  the  pointer  that's  passed  to 
it.  Thus,  the  caller  decides  where  the  object  is  going  to  sit,  and  the 
constructor  is  cal  led  for  that  mennory  as  part  of  the  new-expression 

Although  this  example  shows  only  one  additional  argument, 
there's  nothing  to  prevent  you  from  adding  more  if  you  need  them 
for  other  purposes. 

A dilemma  occurs  when  you  want  to  destroy  the  object.  There's 
only  one  version  of  operator  deletesothere'sno  way  to  say,  "Use 
my  special  deallocator  for  this  object."  You  want  to  call  the 
destructor,  but  you  don't  want  the  memory  to  be  released  by  the 
dynamic  memory  mechanism  because  it  wasn't  allocated  on  the 
heap. 
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The  answer  is  a very  special  syntax.  You  can  explicitly  call  the 
destructor,  as  in 

xp->X::~X();  //  Explicit  destructor  call 

A stern  warning  is  in  order  here.  Somepeopleseethisasa  way  to 
destroy  objects  at  some  ti  me  before  the  end  of  the  scope,  rather 
than  either  adjusting  the  scope  or  (more  correctly)  using  dynamic 
object  creation  ifthey  want  the  object's  lifetime  to  be  determined  at 
runtime.  You  will  haveserious  problems  if  you  call  thedestructor 
this  way  for  an  ordinary  object  created  on  the  stack  because  the 
destructor  will  be  called  again  at  the  end  of  the  scope.  If  you  call 
the  destructor  this  way  for  an  object  that  was  created  on  the  heap, 
thedestructor  will  execute,  but  the  memory  won't  be  released, 
which  probably  isn't  what  you  want.  The  only  reason  that  the 
destructor  can  be  called  explicitly  this  way  isto  support  the 
placement  syntax  for  operator  new 

There's  also  a placement  operator  deletethat  is  only  called  if  a 
constructor  for  a placement  new  expression  throws  an  exception 
(so  that  the  memory  is  automatically  cleaned  up  during  the 
exception).  The  placement  operator  deleUnasan  argument  1 1st  that 
corresponds  to  the  placement  operator  newthat  is  cal  led  before  the 
constructorthrowstheexception.Thistopic  will  be  explored  in  the 
excepti  on  hand  I i ng  chapter  i n Vol  u me  2. 


Summary 

It's  convenient  and  optimally  efficient  to  create  automatic  objects 
on  the  stack,  but  to  solve  the  general  programming  problem  you 
must  be  able  to  create  and  destroy  objects  at  any  ti  me  duri  ng  a 
program's  execution,  particularly  to  respond  to  information  from 
outside  the  program.  Although  C's  dynamic  memory  allocation 
will  get  storage  from  the  heap,  it  doesn't  providetheeaseof  use 
and  guaranteed  construction  necessary  in  C++.  By  bringing 
dynamic  object  creation  into  the  core  of  the  language  with  new  and 
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delete  you  can  create  objects  on  the  heap  as  easily  as  making  them 
on  the  stack.  In  addition,  you  get  a great  deal  of  flexibility.  You  can 
change  the  behavior  of  new  and  del  eteif  they  don't  suit  your 
needs,  particularly  ifthey  aren't  efficient  enough.  Also,  you  can 
modify  what  happens  when  the  heap  runs  out  of  storage. 


Exercises 

Solutions  to  selected  exercises  can  be  found  in  the  electronic  document  TheThinking  in  C++ Annotated 
Solution  Guide,  avail  able  for  a small  feefromwww.BruceEckel.com. 

1.  CreateaclassCountedthatcontainsan  intidand  a 
static  intcountThedefault  constructor  should  begin: 
Counted( ) : id(count++>  (t  should  also  print  its  id  and 

that  it's  being  created.  The  destructor  should  print  that 
it's  being  destroyed  and  itsid.  Test  your  class. 

2.  Prove  to  yourself  that  new  and  deletealwayscall  the 
constructors  and  destructors  by  creating  an  object  of 
class  Counted(from  Exercise  1)  with  new  and 
destroying  it  with  delete  Also  create  and  destroy  an 
array  of  these  objects  on  the  heap. 

3.  C reate  a PStash  object  and  fill  it  with  new  objects  from 
Exercise  1.  Observe  what  happens  when  this  PStash 
object  goes  out  of  scope  and  its  destructor  is  cal  led. 

4.  Createa  vector<  Counted*>end  fill  it  with  pointers  to 
new  Countedobjects (from  Exercise  1).  M ovethrough 
thevectorand  print  the  Counted  objects,  then  move 
through  again  and  deleteeach  one. 

5.  Repeat  Exercise 4,  but  add  a member  function  f(  )to 
Countedthat  prints  a message.  M ovethrough  the  vector 
and  cal  I f(  )for  each  object. 

6.  Repeat  Exercises  using  a PStash 

7 . Repeat  Exerci  se  5 usi  ng  Stack4.hf  rom  C hapter  9. 

8 . Dy  nami  cal  I y create  an  array  of  objects  of  cl  ass  C ou  nted 
(from  Exercise  1).  Call  deletefor  the  resulting  pointer, 
without  the  square  brackets.  Explain  the  results. 
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9.  Create  an  object  of  class  Counted(from  Exercise  1)  using 
new,  cast  the  resulting  pointer  to  a void*  and  delete  that. 
Explain  the  results. 

10.  Execute  NewHandlerxppon  your  machine  to  seethe 
resulting  count.  Calculatethe  amount  of  free  store 
aval  I able  for  your  program. 

11.  Create  a class  with  an  overloaded  operator  new  and 
delete  both  the  single-object  versions  and  the  array 
versions.  Demonstrate  that  both  versions  work. 

12.  Devi  sea  test  for  Framis.cppto  show  yourself 
approximately  how  much  faster  the  custom  new  and 
deleterun  than  the  global  new  and  delete 

13.  Modify  NoM  emery  .cppso  that  it  contains  an  array  of  I nt 
and  so  that  it  actually  allocates  memory  instead  of 
throwing  bad_alloc  In  main( ) setup  a whileloop  like 
the  one  in  NewHandler.cppto  run  out  of  memory  and 
see  what  happens  if  your  operator  newdoes  not  test  to 
see  if  the  memory  issuccessfully  allocated.  Then  add  the 
check  to  your  operator  newand  throw  bad_alloc 

14.  Create  a class  with  a placement  new  with  a second 
argument  of  type  string  The  cl  ass  should  contain  astatic 
vector<string>where  the  second  new  argument  is 
stored.  The  placement  new  should  al  locate  storage  as 
normal.  In  main( ) make  cal  Is  to  your  placement  new 
with  stringargumentsthat  describe  the  cal  Is  (you  may 

want  to  use  the  preprocessor's FILE and LINE 

macros). 

15.  M od ify  A rrayO  peratorN  ew .cpfby  add i ng  a static 

vector<Widget*>that  adds  each  Widgetaddressthat  is 
allocated  in  operator  newand  removes  it  when  it  is 
released  via  operator  delete(You  may  need  to  look  up 
information  about  vectorin  your  Standard  C-H-Library 
documentation  or  in  the2nd  volume  of  this  book, 
availableat  the  Web  site.)  Createa  second  class  called 
M emoryC  heckeithat  has  a destructor  that  prints  out  the 
number  of  Widgetpointers  in  your  vector.  Createa 
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program  with  a single  global  instance  of 
MemoryCheckerand  In  main( ) dynamically  allocate 
and  destroy  several  objects  and  arrays  of  Widget  Show 
that  M emoryC heckeireveals  memory  leaks. 
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14:  I nheritance  & 
Composition 

One  of  the  most  compelling  features  about  C++  is 
code  reuse.  But  to  be  revolutionary,  you  need  to  be 
able  to  do  a lot  more  than  copy  code  and  change  it. 
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That's  the  C approach,  and  it  hasn't  worked  very  well.  As  with 
most  everything  in  C++,  the  solution  revolves  around  the  class. 

You  reuse  code  by  creating  new  classes,  but  instead  of  creating 
them  from  scratch,  you  use  exist!  ng  classes  that  someone  else  has 
built  and  debugged. 

The  tri  ck  i s to  use  the  cl  asses  w ithout  soi  I i ng  the  exi  sti  ng  code.  I n 
this  chapter  you'l  I see  two  ways  to  accompi  i sh  this.  The  f i rst  i s 
quite  straightforward:  You  simply  create  objects  of  your  existing 
class  insidethe  new  class.  This  is  called  composition  because  the  new 
class  is  composed  of  objects  of  exist!  ng  classes. 

The  second  approach  is  subtler.  You  create  a new  class  as  a type  of 
an  existing  class.  You  literally  take  the  form  of  the  existing  class 
and  add  code  to  it,  without  modifying  the  existing  class.  This 
magical  act  is  called  inheritance,  and  most  of  the  work  is  done  by  the 
compi  ler.  I nheritance  is  one  of  the  cornerstones  of  object-oriented 
programming  and  has  additional  implications  that  will  be  explored 
in  Chapter  15. 

It  turns  out  that  much  of  the  syntax  and  behavior  are  similar  for 
both  composition  and  I nheritance  (which  makes  sense;  they  are 
both  ways  of  maki  ng  new  types  from  exi  sti  ng  types).  I n thi  s 
chapter,  you'll  learn  about  these  code  reuse  mechanisms. 


Composition  syntax 

Actually,  you've  been  using  composition  all  along  to  create  cl  asses. 
You'vejust  been  composing  classes  primarily  with  built-in  types 
(and  sometimes  string).  It  turns  out  to  be  almost  as  easy  to  use 
composition  with  user-defined  types. 

C onsi  d er  a cl  ass  that  I s val  u abl  e for  some  reason : 

// : C14 : Useful . h 
//  A class  to  reuse 
#lfndef  USEFUL_H 
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#define  USEFUL_H 


class  X { 
int  i ; 
public : 

X()  {1  = 0;  } 

void  set (int  11)  { 1 = 11;  } 

int  readO  const  { return  1;  } 

int  permute  0 { return  1 = 1 * 47;  } 

}; 

#endif  //  USEFUL_H  ///:- 

The  data  members  are  private!  n this  class,  so  it's  completely  safe  to 
embed  an  object  of  typeX  asa  publicobject  in  a new  class,  which 
makes  the  i nterface  straightforward : 

//:  C14 : Composition . cpp 
//  Reuse  code  with  composition 
#include  "Useful. h" 

class  Y { 
int  i ; 
public : 

X x;  //  Embedded  object 
Y()  { i = 0;  } 

void  f(int  ii)  { i = ii;  } 
int  g()  const  { return  i;  } 

}; 


int  main  ( ) { 

Y y; 

y.f  (47)  ; 

y.x.set(37);  //  Access  the  embedded  object 
} ///:- 

Access!  ng  the  member  functions  of  the  embedded  object  (referred 
to  asa  subobject)  simply  requires  another  member  selection. 

It's  more  common  to  make  the  embedded  objects  private  so  they 
become  part  of  the  underlying  implementation  (which  means  you 
can  change  the  implementation  if  you  want).  The  public!  nterface 
functions  for  your  new  class  then  involvethe  use  of  the  embedded 
object,  but  they  don't  necessarily  mimic  the  object's  interface: 
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//:  C14 : Composition2 . cpp 
//  Private  embedded  objects 
#include  "Useful. h" 


class  Y { 
int  1 ; 

X x;  //  Embedded  object 
public : 

Y()  {1  = 0;  } 

void  f (int  ii)  { 1 = ii;  x. set  (11);  } 

int  g()  const  { return  i * x.readO;  } 
void  permute  0 { x.permuteO;  } 

}; 


int  main  ( ) { 

Y y; 

y.f (47)  ; 
y . permute  ( ) ; 

} ///:- 

Here,  the  permute(  )function  is  carried  through  to  the  new  class 
i nterface,  but  the  other  mennber  functions  of  X are  used  with!  n the 
mennbersof  Y. 


I nheritance  syntax 

The  syntax  for  composition  is  obvious,  but  to  perform  inheritance 
there's  a new  and  different  form. 

When  you  inherit,  you  are  saying,  "This  new  class  is  I ike  that  old 
class."  You  state  this  in  code  by  giving  the  name  of  the  class  as 
usual,  but  before  the  opening  brace  of  the  class  body,  you  put  a 
colon  and  the  name  of  the  base  class  (or  base  classes,  separated  by 
commas,  for  multiple  inheritance).  When  you  do  this,  you 
automatically  get  all  the  data  members  and  member  functions  in 
the  base  class.  H ere's  an  example: 

//:  C14 : Inheritance . cpp 
//  Simple  inheritance 
#include  "Useful. h" 

#include  <iostream> 
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using  namespace  std; 


class  Y : public  X { 

int  1;  //  Different  from  X's  i 
public : 

Y()  { i = 0;  } 

int  change  ( ) { 

i = permute  0;  //  Different  name  call 
return  1; 

} 

void  set (int  ii)  { 
i = ii; 

X::set(ii);  //  Same-name  function  call 


}; 


int  main  ( ) { 

cout  <<  "sizeof(X)  = " <<  sizeof (X)  <<  endl; 

cout  <<  "sizeof (Y)  = " 

<<  sizeof (Y)  <<  endl; 

Y D; 

D . change  ( ) ; 

//X  function  interface  comes  through: 

D . read ( ) ; 

D . permute ( ) ; 

//  Redefined  functions  hide  base  versions: 

D . set  ( 12 ) ; 

} ///:- 

You  can  seeY  being  inherited  fromX,  which  means  that  Y will 
contain  all  the  data  elements  in  X and  all  the  member  functions  in 
X.  I n fact,  Y contai ns  a subobject  of  X just  as  if  you  had  created  a 
member  object  of  X insideY  instead  of  inheriting  from  X.  Both 
member  objects  and  base  class  storage  are  referred  to  as  subobjects. 

All  theprivateelementsofX  are  still  privatein  Y;that  is,  just 
becauseY  inherits  from  X doesn't  mean  Y can  break  the  protection 
mechanism.  The  privateelements  of  X are  sti  1 1 there,  they  take  up 
space  - you  just  can't  access  them  directly. 

In  main(  )you  can  seethatY's  data  elements  are  combined  with  X's 
because  the  si  zeof  (Y)i  s tw  i ce  as  bi  g as  si  zeof  (X) 
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You'll  notice  that  the  base  cl  ass  is  preceded  by  public  During 
inheritance,  everything  defaults  to  private  If  the  base  class  were 
not  preceded  by  public  it  would  mean  that  all  of  the  public 
members  of  the  base  class  would  be  private!  n the  derived  class. 
This  is  almost  never  what  you  want^;  thedesired  result  isto  keep 
all  thepublicmembersof  the  base  class  public!  n the  derived  class. 
You  dothisby  using  the  publickeyword  during  inheritance. 

In  change( ) the  base-class  permute(  Kunction  is  called.  The 
derived  class  has  direct  access  to  all  the  public  base-class  functions. 

Theset(  )fu notion  in  the  derived  class  recfef/nes  the set(  )fu notion  in 
the  base  cl  ass.  That  is,  if  you  call  the  functions  read  ( )and 
permute(  Koran  object  of  type  Y,  you'll  get  the  base-class  versions 
of  those  functions  (you  can  see  this  happen  inside  main(  |.  But  if 
you  call  set(  )for  a Y object,  you  get  the  redefined  version.  This 
means  that  if  you  don't  I ike  the  version  of  afunction  you  get 
during  inheritance,  you  can  change  what  it  does.  (You  can  also  add 
completely  new  functions  like change( )) 

However,  when  you're  redefining  afunction,  you  may  still  want  to 
call  the  base-class  version.  If,  insideset( ) you  simply  call  set( ) 
you'll  get  the  local  version  of  thefunction  - a recursive  function 
call.  To  call  the  base-class  version,  you  must  explicitly  name  the 
base  class  using  the  scope  resolution  operator. 


The  constructor  initializer  list 

You'veseen  how  important  it  is  in  C-H-to  guarantee  proper 
initialization,  and  it's  no  different  during  composition  and 
inheritance.  When  an  object  is  created,  the  compiler  guarantees  that 
constructors  for  all  of  its  subobjects  are  called.  In  the  examples  so 


^ I n J ava,  the  compi  I er  won't  I et  you  decrease  the  access  of  a member  d u ri  ng 
inheritance. 
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far,  all  of  the  subobjects  have  default  constructors,  and  that's  what 
the  compiler  automatically  calls.  But  what  happens  if  your 
subobjects  don't  have  default  constructors,  or  if  you  want  to  change 
a default  argument  in  a constructor?  This  is  a problem  because  the 
new  class  constructor  doesn't  have  permission  to  access  the  private 
data  elements  of  the  subobject,  so  it  can't  initializethem  directly. 

The  solution  issimple:  Call  the  constructor  for  the  subobject.  C++ 
provides  a special  syntax  for  this,  the  constructor  initializer  list.  The 
form  of  the  constructor  I ni ti  al  I zer  1 1 st  echoes  the  act  of  I n heritance. 
With  inheritance,  you  put  the  base  classes  after  a colon  and  before 
the  opening  braceof  the  class  body.  In  the  constructor  initializer 
1 1st,  you  put  the  cal  Is  to  subobject  constructors  after  the  constructor 
argument  list  and  a colon,  but  before  the  opening  brace  of  the 
function  body.  For  aclassMyTypq  inherited  from  Bar,  this  might 
look  I ike  this: 


I MyType : : MyType ( int  i)  : Bar(i)  { //  ... 

if  Bar  has  a constructor  that  takes  a si  ngl  e i nt  argu ment. 

Member  object  initialization 

It  turns  out  that  you  usethisvery  same  syntax  for  member  object 
initialization  when  using  composition.  For  composition,  you  give 
the  names  of  the  objects  i nstead  of  the  class  names.  If  you  have 
more  than  one  constructor  call  in  the  initializer  list,  you  separate 
the  cal  Is  with  commas: 


MyType2 : : MyType2 ( int  i)  : Bar(i),  m(i+l)  { //  ... 

Thi  s i s the  begi  n n i ng  of  a constru  ctor  for  cl  ass  M yT y pe?  w hi  ch  i s 
inherited  from  Bar  and  contains  a member  object  called  m.  Note 
that  while  you  can  see  the  type  of  the  base  cl  ass  i n the  constructor 
initializer  list,  you  only  seethe  member  object  identifier. 
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Built-in  types  in  the  initializer  list 

The  constructor  initializer  list  allows  you  to  explicitly  call  the 
constructors  for  mennber  objects.  I n fact,  there's  no  other  way  to  cal  I 
those  constructors.  The  idea  is  that  the  constructors  are  all  called 
before  you  get  i nto  the  body  of  the  new  class's  constructor.  That 
way,  any  callsyou  maketo  mennber  functions  of  subobjects  will 
always  go  to  initialized  objects.  There's  no  way  to  get  to  the 
opening  braceof  the  constructor  without  some  constructor  being 
called  for  all  the  member  objects  and  base-class  objects,  even  if  the 
compiler  must  make  a hidden  call  to  a default  constructor.  This  is  a 
further  enforcement  of  the  C-H- guarantee  that  no  object  (or  part  of 
an  object)  can  get  out  of  the  start!  ng  gate  without  its  constructor 
being  called. 

This  idea  that  all  of  the  member  objects  are  initialized  by  the  time 
the  opening  braceof  the  constructor  is  reached  is  a convenient 
programming  aid  as  well.  Once  you  hit  the  opening  brace,  you  can 
assume  all  subobjects  are  properly  initialized  and  focus  on  specific 
tasks  you  want  to  accompi  i sh  i n the  constructor.  H owever,  there's  a 
hitch:  What  about  member  objects  of  built-in  types,  which  don't 
/lai/e  constructors? 

To  make  the  syntax  consistent,  you  are  allowed  to  treat  built-in 
types  as  if  they  have  a single  constructor,  which  takes  a single 
argu  ment:  a vari  abl  e of  the  same  type  as  the  vari  abl  e you  're 
initializing.  Thus,  you  can  say 

//:  C14 : PseudoConstructor . cpp 
class  X { 
int  i ; 
float  f; 
char  c; 
char*  s; 
public : 

X()  : 1(7),  f(1.4),  c('x'),  s ("howdy")  {} 

}; 


int  main  ( ) { 
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X X ; 

int  i(lOO);  //  Applied  to  ordinary  definition 
int*  ip  = new  int (47); 

} ///:- 

The  action  of  these  "pseudo-constructor  calls"  isto  perform  a 
simpleassignment.  It'sa  convenient  technique  and  a good  coding 
style,  so  you'll  see  it  used  often. 

It's  even  possible  to  use  the  pseudo-constructor  syntax  when 
creati  ng  a vari  abl  e of  a bu  i I t-i  n ty  pe  outsi  d e of  a cl  ass: 

int  i ( 100 ) ; 

int*  ip  = new  int  (47); 

Thi  s makes  bu  i I t-i  n types  act  a I itti  e bit  more  I i ke  objects. 
Remember,  though,  that  these  are  not  real  constructors.  I n 
particular,  if  you  don't  explicitly  make  a pseudo-constructor  call, 
no  initialization  is  performed. 


Combining  composition  & inheritance 

Of  course,  you  can  use  composition  & inheritance  together.  The 
following  example  shows  the  creation  of  a more  complex  class 
using  both  of  them. 

//:  C14 : Combined. cpp 
//  Inheritance  & composition 

class  A { 
int  i ; 
public : 

A ( int  ii ) : i ( ii ) { } 

~A ( ) { } 

void  f ( ) const  { } 

}; 


class  B { 
int  i ; 
public : 

B(int  ii)  : i(ii)  {} 
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~B()  {} 

void  f ( ) const  { } 


class  C : public  B { 

A a; 
public : 

C(int  11)  : B(ii),  a(ii)  {} 

~C()  {}  //  Calls  ~A()  and  ~B() 

void  f()  const  { //  Redefinition 

a.f  0 ; 

B:  :f  0 ; 


}; 


int  main  ( ) { 

C c(47)  ; 

} ///:- 

C inherits  from  B and  hasa  member  object  ("iscomposed  of')  of 
typeA.  You  can  see  the  constructor  initializer  list  contains  callsto 
both  the  base-class  constructor  and  the  member-object  constructor. 

Thefunction  C::f(  )redefinesB::f( ) which  it  inherits,  and  also  calls 
the  base-class  version.  In  addition,  itcallsa.f( ) Noticethat  the  only 
time  you  can  talk  about  redefinition  of  functions  is  during 
inheritance;  with  a member  object  you  can  only  manipulate  the 
public  i nterface  of  the  object,  not  redefineit.  In  addition,  calling  f( ) 
for  an  object  of  class  C would  not  cal  I a.f(  )if  C::f(  )had  not  been 
defined,  whereas  it  would  call  B::f( ) 

Automatic  destructor  calls 

Although  you  are  often  required  to  make  explicit  constructor  calls 
in  the  initializer  list,  you  never  need  to  make  explicit  destructor 
calls  because  there's  only  one  destructor  for  any  class,  and  it 
doesn't  take  any  arguments.  However,  the  compiler  still  ensures 
that  all  destructors  are  cal  led,  and  that  means  all  of  the  destructors 
in  the  entire  hierarchy,  starting  with  the  most-derived  destructor 
and  working  back  to  the  root. 
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It's  worth  emphasizi  ng  that  constructors  and  destructors  are  quite 
unusual  in  that  every  one  in  the  hierarchy  is  called,  whereas  with  a 
normal  member  function  only  that  function  is  called,  but  not  any  of 
the  base-class  versions.  If  you  also  want  to  call  the  base-class 
version  of  a normal  member  function  that  you're  overriding,  you 
must  do  it  explicitly. 

Order  of  constructor  & destructor  calls 

It's  interesting  to  know  the  order  of  constructor  and  destructor  calls 
when  an  object  has  many  subobjects.  The  following  example  shows 
exactly  how  it  works: 

//:  C14 : Order . cpp 
//  Constructor/destructor  order 
#include  <fstream> 
using  namespace  std; 
of stream  out ( "order . out ")  ; 

#define  CLASS (ID)  class  ID  { \ 
public:  \ 

ID(int)  { out  <<  #ID  " constructorXn" ; } \ 

~ID()  { out  <<  #ID  " destructorXn" ; } \ 

}; 


CLASS (Basel)  ; 

CLASS (Member 1) ; 

CLASS (MemberC) ; 

CLASS (Members) ; 

CLASS (Member!) ; 

class  Derivedl  : public  Basel  { 

Memberl  ml; 

Members  m2; 
public : 

Derivedl ( int ) : m2 ( 1 ) , ml (2),  Basel (3)  { 

out  <<  "Derivedl  constructorXn"; 

} 

~Derivedl ( ) { 

out  <<  "Derivedl  destructor\n" ; 


}; 
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class  Derived2  : public  Derivedl  { 

Members  m3; 

Member4  m4 ; 
public : 

Derived2()  : mS(l),  Derivedl (2),  m4(3)  { 

out  <<  "Derived2  constructor\n" ; 

} 

~Derived2 ( ) { 

out  <<  "Derived2  destructor\n" ; 


}; 


int  main  ( ) { 

Derived2  d2 ; 

} ///:- 

First,  an  of  stream  object  is  created  to  send  all  the  output  to  a file. 
Then,  to  save  some  typing  and  demonstrate  a macro  techniquethat 
will  be  replaced  by  a much  improved  technique  in  Chapter  16,  a 
macro  is  created  to  build  some  of  the  classes,  which  are  then  used 
in  inheritance  and  composition.  Each  of  the  constructors  and 
destructors  report  themselves  to  the  trace  file.  Note  that  the 
constructors  are  not  default  constructors;  they  each  have  an  int 
argument.  The  argument  itself  has  no  identifier;  its  only  reason  for 
existence  is  to  force  you  to  explicitly  call  the  constructors  in  the 
initializer  list.  (Eliminating  the  identifier  prevents  compiler 
warning  messages.) 

The  output  of  this  program  is 

Basel  constructor 
Memberl  constructor 
Member2  constructor 
Derivedl  constructor 
Member3  constructor 
Member4  constructor 
Derived2  constructor 
Derived2  destructor 
Member4  destructor 
Member3  destructor 
Derivedl  destructor 
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Member2  destructor 
Memberl  destructor 
Basel  destructor 

Y ou  can  see  that  constructi  on  starts  at  the  very  root  of  the  cl  ass 
hierarchy,  and  that  at  each  level  the  base  class  constructor  is  called 
fi  rst,  fol  lowed  by  the  mennber  object  constructors.  The  destructors 
are  cal  led  I n exactly  the  reverse  order  of  the  constructors  - this  is 
I mportant  because  of  potential  dependencies  (I  n the  derived-class 
constructor  or  destructor,  you  must  beableto  assume  that  the  base- 
class  subobject  is  still  aval  I able  for  use,  and  has  already  been 
constructed  - or  not  destroyed  yet). 

It's  also  interest!  ng  that  the  order  of  constructor  cal  Is  for  member 
objects  is  completely  unaffected  by  the  order  of  the  cal  Is  in  the 
constructor  initializer  list.  The  order  isdetermined  by  the  order  that 
the  member  objects  are  declared  in  the  cl  ass.  If  you  could  change 
the  order  of  constructor  cal  Is  via  the  constructor  initializer  list,  you 
could  havetwo  different  call  sequences  in  two  different 
constructors,  but  the  poor  destructor  wouldn't  know  how  to 
properly  reversetheorder  of  the  cal  Is  for  destruction,  and  you 
could  end  up  with  a dependency  problem. 


Name  hiding 

If  you  inherit  a class  and  provideanew  definition  for  one  of  its 
member  fu  net!  ons,  there  are  two  possi  bi  1 1 ti  es.  The  fi  rst  I s that  you 
provide  the  exact  signature  and  return  type  in  the  derived  class 
definitionasinthe  base  cl  ass  d ef  I n 1 1 1 on . T h I s I s cal  I ed  r ecfef/n  /n  g for 
ordinary  member  functions  and  oi/err/'d/ngi  when  the  base  cl  ass 
member  function  is  a virtual  function  (virtual  functions  are  the 
normal  case,  and  will  be  covered  in  detail  in  Chapter  15).  But  what 
happens  if  you  change  the  member  function  argument  list  or  return 
type  in  the  derived  class?  Here's  an  example: 

//:  C14 : NameHiding . epp 

//  Hiding  overloaded  names  during  inheritance 
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#include  <iostream> 
#include  <string> 
using  namespace  std; 


class  Base  { 
public : 

int  f ( ) const  { 

cout  <<  "Base : : f ( ) \n" ; 
return  1; 

} 

int  f (string)  const  { return  1;  } 

void  g ( ) { } 

}; 

class  Derivedl  : public  Base  { 
public : 

void  g ( ) const  { } 

}; 

class  Derived2  : public  Base  { 
public : 

//  Redefinition: 
int  f ( ) const  { 

cout  <<  "Derived2 : : f ( ) \n" ; 
return  2; 

} 

}; 

class  DerivedS  : public  Base  { 
public : 

//  Change  return  type: 

void  f()  const  { cout  <<  "DerivedS : : f ( ) \n" ; } 

}; 

class  Derived!  : public  Base  { 
public : 

//  Change  argument  list: 
int  f ( int ) const  { 

cout  <<  "Derived! :: f 0 \n" ; 
return  !; 

} 

}; 

int  main  ( ) { 

string  s ("hello"); 
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Derivedl  dl; 
int  X = dl . f ( ) ; 
dl . f (s)  ; 

Derived2  d2 ; 

X = d2 . f ( ) ; 

//!  d2.f(s);  //  string  version  hidden 

DerivedS  d3; 

//!  x=d3.f();  //  return  int  version  hidden 

Derivedi  d4 ; 

//!  x=d4.f();  //  f()  version  hidden 

X = d4 . f (1)  ; 

} ///:- 

In  Baseyou  see  an  overloaded  function  f( ),  and  Derived  Id  oesn't 
make  any  changes  to  f(  )but  it  does  redefine  g( ).  In  main(  )you 
can  see  that  both  overloaded  versions  of  f( ) are  available  in 
Derivedl  However,  Derived2redefines  one  overloaded  version  of 
fObut  not  the  other,  and  the  result  is  that  the  second  overloaded 
form  is  unavailable.  In  Derived3  changing  the  return  type  hides 
both  the  base  cl  ass  versions,  and  Derived4showsthat  changing  the 
argument  list  also  hides  both  the  base  cl  ass  versions.  In  general,  we 
can  say  that  anyti  me  you  redefine  an  overloaded  function  name 
from  the  base  class,  al  I the  other  versions  are  automatical  ly  hidden 
in  the  new  class.  In  Chapter  15,  you'll  seethat  the  addition  of  the 
virtuai  keyword  affects  function  overloading  a bit  more. 

If  you  change  the  interface  of  the  base  cl  ass  by  modifying  the 
signature  and/  or  return  type  of  a member  function  from  the  base 
class,  then  you're  using  the  class  in  adifferent  way  than  inheritance 
is  normally  intended  to  support.  It  doesn't  necessarily  mean  you're 
doing  it  wrong,  it'sjust  that  the  ultimate  goal  of  inheritance  is  to 
support  polymorphism,  and  if  you  change  the  function  signature  or 
return  type  then  you  are  actual  ly  changing  the  interface  of  the  base 
class.  If  this  is  what  you  haveintended  to  do  then  you  are  using 
inheritance  primarily  to  reuse  code,  and  not  to  maintain  the 
common  i nterface  of  the  base  class  (which  is  an  essential  aspect  of 
polymorphism).  In  general,  when  you  use  inheritance  this  way  it 
means  you 're  taking  a general -purpose  cl  ass  and  specializing  it  for 
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a particular  need  - which  is  usually,  but  not  always,  considered  the 
real  m of  composition. 

For  example,  consider  the  Stack  cl  ass  from  Chapter  9.  One  of  the 
problems  with  that  class  is  that  you  had  to  perform  a cast  every 
time  you  fetched  a pointer  from  the  container.  This  is  not  only 
tedious,  it's  unsafe- you  could  cast  the  pointer  to  anything  you 
want. 

An  approach  that  seems  better  at  fi  rst  glance  is  to  special  ize  the 
general  Stack  cl  ass  using  inheritance.  Here'san  example  that  uses 
the  cl  ass  from  C hapter  9: 

//:  C14 : InheritStack . cpp 
//  Specializing  the  Stack  class 
#include  " . . /CO 9/Stack4 . h" 

#include  ".. /require . h" 

#include  <iostream> 

#include  <fstream> 

#include  <string> 
using  namespace  std; 

class  StringStack  : public  Stack  { 
public : 

void  push (string*  str)  { 

Stack:  :push(str)  ; 

} 

string*  peek()  const  { 

return  ( string* ) Stack :: peek ()  ; 

} 

string*  pop ( ) { 

return  ( string* ) Stack :: pop () ; 

} 

-StringStack ( ) { 

string*  top  = pop(); 
while (top)  { 
delete  top; 
top  = pop ( ) ; 


}; 
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int  main  ( ) { 

if stream  in ( " Inherit Stack . cpp" ) ; 
assure (in,  " Inherit Stack . cpp" ) ; 
string  line; 

StringStack  textlines; 
while (getline (in,  line)) 

textlines . push (new  string  (line) ) ; 
string*  s; 

while((s  = textlines . pop  ( ) ) !=  0)  { //  No  cast! 

cout  <<  *s  <<  endl; 
delete  s; 

} 

} ///:- 

Si  nee  all  of  the  member  fu  nrti  ons  i n Stack4.hare  inlines,  nothing 
needs  to  be  linked. 

StringStackspecializes  Stack  so  that  push(  )will  accept  only 
String  pointers.  Before,  Stackwould  accept  void  pointers,  so  the 
user  had  no  type  checking  to  make  sure  the  proper  pointers  were 
inserted.  In  addition,  peek(  )and  pop(  )now  return  String  pointers 
instead  of  void  pointers,  so  no  cast  is  necessary  to  use  the  pointer. 

Amazingly  enough,  this  extra  type-checking  safety  is  free  in 
push( ) peek( ) and  pop( )!  The  compiler  is  being  given  extra  type 
information  that  it  uses  at  compile-time,  but  the  functions  are 
inlined  and  no  extra  code  is  generated. 

Name  hiding  comes  into  play  here  because,  in  particular,  the 
push(  )function  has  a different  signature:  the  argument  list  is 
different.  If  you  had  two  versions  of  push(  )in  the  same  class,  that 
would  be  overloading,  but  in  this  case  overloading  isnot  what  we 
want  because  that  would  still  allow  you  to  pass  any  kind  of  pointer 
intopush(  )asavoid*.  Fortunately,  C-h- hides  the  push(void*) 
version  in  the  base  cl  ass  in  favor  of  the  new  version  that'sdefined 
in  the  derived  class,  and  therefore  it  only  allows  us  to  push(  )string 
poi  nters  onto  the  Stri  ngStack 
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Because  wecan  now  guarantee  that  we  know  exactly  what  kind  of 
objects  are  i n the  contai  ner,  the  destructor  works  correctly  and  the 
ownership  problenn  is  solved  - or  at  least,  one  approach  to  the 
ownership  problenn.  Here,  if  you  push(  )a  string  pointer  onto  the 
Stri  ngStack  then  (accord  i ng  to  the  sennanti  cs  of  the  Stri  ngStack 
you're  also  passing  ownership  of  that  pointer  to  the  Stri ngStack  If 
you  pop(  )the  pointer,  you  not  only  get  the  pointer,  but  you  also 
get  ownership  of  that  pointer.  Any  pointers  that  are  I eft  on  the 
Stri  ngStackw  hen  its  destructor  is  called  are  then  deleted  by  that 
destructor.  And  si  nee  these  are  always  string  pointers  and  the 
deietestatennent  is  working  on  string  pointers  instead  of  void 
pointers,  the  proper  destruction  happens  and  everything  works 
correctly. 

There  is  a drawback:  this  class  works  only  for  string  poi  nters.  If  you 
want  a Stackthat  works  with  some  other  kind  of  object,  you  must 
write  a new  version  of  the  cl  ass  so  that  it  works  only  with  your  new 
kind  of  object.  This  rapidly  becomes  tedious,  and  is  finally  solved 
using  templates,  as  you  will  see  in  Chapter  16. 

Wecan  make  an  additional  observation  about  this  example:  it 
changes  the  i nterface  of  the  Stack  i n the  process  of  i nheritance.  If 
the  interface  is  different,  then  a StringStackreally  isn't  a Stack  and 
you  will  never  be  able  to  correctly  usea  StringStackas  a Stack 
This  makes  the  use  of  inheritance  questionable  here;  if  you're  not 
creating  a StringStackthat  /s-a  type  of  Stack  then  why  are  you 
inheriting?A  more  ap  prop  date  version  of  Stri  ngStackwi  1 1 be 
shown  later  in  this  chapter. 


Functions  that  don't  automatically 
inherit 

Not  all  functions  are  automatically  inherited  from  the  base  class 
into  the  derived  class.  Constructors  and  destructors  deal  with  the 
creation  and  destruction  of  an  object,  and  they  can  know  what  to 
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do  with  the  aspects  of  the  object  only  for  their  particular  class,  so  al  I 
the  constructors  and  destructors  in  the  hierarchy  below  them  must 
be  cal  led.  Thus,  constructors  and  destructors  don't  inherit  and  must 
be  created  specially  for  each  derived  class. 

In  addition,  theoperator=doesn't  inherit  because  it  performs  a 
constructor-1  ike  activity.  That  is,  just  because  you  know  how  to 
assign  all  the  members  of  an  object  on  theleft-hand  sideof  the  = 
from  an  object  on  the  right-hand  side  doesn't  mean  that  assignment 
will  still  havethe  same  meaning  after  inheritance. 

In  lieu  of  inheritance,  these  functions  are  synthesized  by  the 
compiler  if  you  don't  create  them  yourself.  (With  constructors,  you 
can't  create  any  constructors  in  order  for  the  compiler  to  synthesize 
the  default  constructor  and  the  copy-constructor.)  This  was  briefly 
descri  bed  i n Chapter  6.  The  synthesized  constructors  use 
memberwise  initialization  and  the  synthesized  operator=uses 
memberwise  assignment.  Here'san  example  of  the  functions  that 
are  synthesized  by  the  compiler: 

//:  C14 : SynthesizedFunctions . cpp 

//  Functions  that  are  synthesized  by  the  compiler 
#include  <iostream> 
using  namespace  std; 

class  GameBoard  { 
public : 

GameBoard 0 { cout  <<  "GameBoard () \n" ; } 

GameBoard (const  GameBoard&)  { 

cout  <<  "GameBoard (const  GameBoard& ) \n" ; 


GameBoard&  operator=  (const  GameBoard&)  { 
cout  <<  "GameBoard :: operator= 0 \n" ; 
return  *this; 

} 

-GameBoard 0 { cout  <<  "-GameBoard () \n" ; } 


class  Game  { 

GameBoard  gb;  //  Composition 
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public : 

//  Default  GameBoard  constructor  called: 

Game ( ) { cout  <<  "Game()\n";  } 

//  You  must  explicitly  call  the  GameBoard 
//  copy-constructor  or  the  default  constructor 
//  is  automatically  called  instead: 

Game (const  Game&  g)  : gb(g.gb)  { 
cout  <<  "Game (const  Game&)\n"; 

} 

Game(int)  { cout  <<  "Game (int) \n";  } 

Game&  operator= (const  Game&  g)  { 

//  You  must  explicitly  call  the  GameBoard 
//  assignment  operator  or  no  assignment  at 
//  all  happens  for  gb ! 
gb  = g . gb ; 

cout  <<  "Game : : operator= ( ) \n" ; 
return  *this; 

} 

class  Other  {};  //  Nested  class 
//  Automatic  type  conversion: 
operator  Other ()  const  { 

cout  <<  "Game :: operator  Other ()\n"; 
return  Other (); 

} 

-GarneO  { cout  <<  "~Game()\n";  } 


class  Chess  : public  Game  {}; 

void  f (Game :: Other ) {} 

class  Checkers  : public  Game  { 
public : 

//  Default  base-class  constructor  called: 
Checkers  0 { cout  <<  "Checkers () \n" ; } 

//  You  must  explicitly  call  the  base-class 
//  copy  constructor  or  the  default  constructor 
//  will  be  automatically  called  instead: 
Checkers (const  Checkers&  c)  : Game (c)  { 

cout  <<  "Checkers (const  Checkers&  c)\n"; 

} 

Checkers&  operator= (const  Checkers&  c)  { 

//  You  must  explicitly  call  the  base-class 
//  version  of  operator=()  or  no  base-class 
//  assignment  will  happen: 
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Game : : operator= (c) ; 

cout  <<  "Checkers :: operator= 0 \n"  ; 
return  *this; 


}; 


int  main  ( ) { 

Chess  dl;  //  Default  constructor 
Chess  d2(dl);  //  Copy-constructor 

//!  Chess  d3(l);  //  Error:  no  int  constructor 
dl  = d2;  //  Operator=  synthesized 

f(dl);  //  Type-conversion  IS  inherited 
Game : : Other  go; 

//!  dl  = go;  //  Operator=  not  synthesized 
//  for  differing  types 
Checkers  cl,  c2(cl); 
cl  = c2; 

} ///:- 

The  constructors  and  the  operator=for  G ameBoardand  G ame 
announcethennselvessoyou  can  see  when  they're  used  by  the 
compiler.  In  addition,  the  operator  Other(  jDerforms  automatic 
type  conversion  from  a G ame  object  to  an  object  of  the  nested  class 
Other  The  class  Chesssimply  inherits  from  Game  and  creates  no 
functions  (to  see  how  the  compiler  responds).  The  function  f( ) 
takes  an  Other  object  to  test  the  automatic  type  conversion 
function. 

In  main( ) the  synthesized  default  constructor  and  copy- 
constructor  for  the  derived  cl  ass  C hessare  cal  led . The  G ame 
versions  of  these  constructors  are  cal  led  as  part  of  the  constructor- 
call  hierarchy.  Even  though  it  looks  like  inheritance,  new 
constructors  are  actual  I y synthesized  by  the  compi  ler.  As  you 
might  expect,  no  constructors  with  arguments  are  automatically 
created  because  that's  too  much  for  the  compi  ler  to  i ntuit. 

The  operators!  sal  so  synthesized  as  a new  function  in  Chess  using 
memberwise  assignment  (thus,  the  base-class  version  iscalled) 
because  that  function  was  not  explicitly  written  in  the  new  class. 
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And  of  course thedestructor  was  automatically  synthesized  by  the 
compiler. 

Because  of  all  these  rules  about  rewriting  functions  that  handle 
object  creation,  it  may  seem  a little  strange  at  first  that  the 
automatic  type  conversion  operator  is  inherited.  But  it's  not  too 
unreasonable  - if  there  are  enough  pieces  in  Game  to  make  an 
Otherobject,  those  pieces  are  still  therein  anything  derived  from 
Game  and  the  type  conversion  operator  is  still  valid  (even  though 
you  may  i n fact  want  to  redefi  ne  it). 

operator=is  synthesized  only  for  assign!  ng  objects  of  the  same  type. 
If  you  want  to  assign  onetypeto  another  you  must  always  write 
that  operator=yourself. 

If  you  look  more  closely  at  Game  you'll  seethat  the  copy- 
constructor  and  assignment  operators  have  expl  icit  cal  Is  to  the 
member  object  copy-constructor  and  assignment  operator.  You  will 
normally  want  to  do  this  because  otherwise,  in  the  case  of  the  copy- 
constructor,  the  default  member  object  constructor  will  be  used 
instead,  and  in  the  case  of  the  assignment  operator,  no  assignment 
at  all  will  be  donefor  the  member  objects! 

Lastly,  look  at  Checkers  which  explicitly  writes  out  the  default 
constructor,  copy-constructor,  and  assignment  operators.  In  the 
case  of  the  default  constructor,  the  default  base-class  constructor  is 
automatically  called,  and  that'stypically  what  you  want.  But,  and 
thisisan  important  point,  as  soon  as  you  decideto  write  your  own 
copy-constructor  and  assignment  operator,  the  compiler  assumes 
that  you  know  what  you're  doing  and  does  not  automatically  call 
the  base-class  versions,  as  it  does  in  the  synthesized  functions.  If 
you  want  the  base  class  versions  called  (and  you  typically  do)  then 
you  must  explicitly  call  them  yourself.  I n the C heckerscopy- 
constructor,  this  call  appears  in  the  constructor  initializer  list: 

Checkers (const  Checkers&  c)  : Game (c)  { 
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I n the  C heckersassign merit  operator,  the  base  class  cal  I is  the  fi  rst 
line  in  the  function  body: 

I Game : : operator= (c)  ; 

These  cal  Is  should  be  part  of  the  canonical  form  that  you  use 
whenever  you  inherit  a class. 

I nheritance  and  static  member  functions 

stati c member  f u net!  ons  act  the  same  as  non-stati  c member 
functions: 

1.  They  inherit  into  the  derived  class. 

2.  If  you  redefine  a static  member,  all  the  other  overloaded 
functions  in  the  base  class  are  hidden. 

3.  If  you  changethe  signature  of  a function  in  the  base  cl  ass,  all 
thebaseclass  versions  with  that  function  name  are  hidden 
(this  is  really  a variation  of  the  previous  point). 

However,  statiemember  functions  cannot  be  virtual  (a  topic 
covered  thoroughly  in  Chapter  15). 


Choosing  composition  vs.  inheritance 

Both  composition  and  inheritance  place  subobjectsinsideyour  new 
class.  Both  use  the  constructor  initializer  list  to  construct  these 
subobjects.  You  may  now  be  wondering  what  the  difference  is 
between  the  two,  and  when  to  choose  one  over  the  other. 

Composition  is  generally  used  when  you  wantthefeaturesof  an 
existing  class  inside  your  new  class,  but  not  its  interface.  That  is, 
you  embed  an  object  to  implement  features  of  your  new  class,  but 
theuserof  your  new  cl  ass  sees  the  interface  you've  defined  rather 
than  the  interface  from  the  original  class.  To  do  this,  you  follow  the 
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typical  path  of  embedding  privateobjects  of  existing  classes  inside 
your  new  class. 

Occasionally,  however,  it  makes  sense  to  allow  the  cl  ass  user  to 
directly  access  the  composition  of  your  new  class,  that  is,  to  make 
the  member  objects  public  The  member  objects  use  access  control 
themselves,  so  this  is  a safe  thing  to  do  and  when  the  user  knows 
you're  assembling  a bunch  of  parts,  it  makes  the  interface  easier  to 
understand.  A Car  cl  ass  Isa  good  example: 

// : C14 : Car . cpp 
//  Public  composition 

class  Engine  { 
public : 

void  start  0 const  {} 
void  rev ( ) const  {} 
void  stopO  const  {} 

}; 


class  Wheel  { 
public : 

void  inflate (int  psi)  const  {} 

}; 


class  Window  { 
public : 

void  rollup  0 const  {} 
void  rolldownO  const  {} 


class  Door  { 
public : 

Window  window; 

void  openO  const  {} 

void  close  0 const  {} 


class  Car  { 
public : 

Engine  engine; 

Wheel  wheel [4]; 

Door  left,  right;  //  2-door 
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car . left . window . rollup ( ) ; 
car . wheel [0]  .inflate  (72) ; 

} III-.- 

Because  the  compositi  on  of  a C ar  i s part  of  the  anal  ysi  s of  the 
problem  (and  not  simply  part  of  the  underlying  design),  making 
the  members  publicassiststheclient  programmer's  understanding 
of  how  to  use  the  class  and  requires  less  code  complexity  for  the 
creator  of  the  class. 

With  a little  thought,  you'll  also  see  that  it  would  make  no  sense  to 
composeaCarusing  a "vehicle"  object  - a car  doesn't  contain  a 
vehicle,  it/sa  vehicle.  The /s-a  relationship  is  expressed  with 
inheritance,  and  thehas-a  relationship  isexpressed  with 
composition. 

Subtyping 

N ow  suppose  you  want  to  create  a type  of  ifstreamobject  that  not 
only  opens  a f i I e but  al  so  keeps  track  of  the  name  of  the  f i I e.  Y ou 
can  use  composition  and  embed  both  an  ifstreamand  astringinto 
the  new  class: 

//:  C14 : FNamel . cpp 

//  An  f stream  with  a file  name 

#include  ".. /require . h" 

#include  <iostream> 

#include  <fstream> 

#include  <string> 
using  namespace  std; 

class  FNamel  { 
ifstream  file; 
string  fileName; 
bool  named; 
public : 

FNamel 0 : named(false)  {} 
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FNamel (const  strings  fname) 

: fileName (fname) , file (fname . c_str () ) { 

assure (file,  fileName); 
named  = true; 

} 

string  name()  const  { return  fileName;  } 

void  name (const  strings  newName)  { 

if (named)  return;  //  Don't  overwrite 
fileName  = newName; 
named  = true; 

} 

operator  ifstreamSO  { return  file;  } 


int  main  ( ) { 

FNamel  f lie ( "FNamel . cpp" ) ; 
cout  <<  file. name  0 <<  endl; 

//  Error:  close  ()  not  a member: 

// ! file . close ( ) ; 

} ///:- 

There's  a problem  here,  however.  An  attempt  is  made  to  allow  the 
use  of  the  FNamelobject  anywhere  an  ifstreamobjert  isused  by 
including  an  automatic  type  conversion  operator  from  FNamelto 
an  ifstream&  Butin  main,  the  line 

f lie . close  ( ) ; 

will  not  compile  because  automatic  type  conversion  happens  only 
in  function  calls,  not  during  member  selection.  So  this  approach 
won't  work. 

A second  approach  is  to  add  the  definition  of  close(  )to  FNamel 

void  closeO  { f ile  . close  ()  ; } 

This  will  work  if  there  are  only  a few  functions  you  want  to  bring 
through  from  theifstreamclass.  In  that  case  you're  only  using  part 
of  the  cl  ass,  and  composition  is  appropriate. 

But  what  if  you  want  everything  in  the  class  to  come  through?  This 
is  cal  led  subtyping  because  you're  making  a new  type  from  an 
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©(i  sting  type,  and  you  want  your  new  type  to  have  exactly  the 
same  i nterface  as  the  exist!  ng  type  (pi  us  any  other  member 
functions  you  want  to  add),  so  you  can  use  it  everywhere  you'd  use 
the  exi sti  ng  type.  Thi s i s where  i nheritance  i s essenti al . You  can  see 
that  subtyping  solves  the  problem  in  the  preceding  example 
perfectly: 

//:  C14 : FName2 . cpp 
//  Subtyping  solves  the  problem 
#include  /require . h" 

#include  <iostream> 

#include  <fstream> 

#include  <string> 
using  namespace  std; 

class  FName2  : public  ifstream  { 
string  fileName; 
bool  named; 
public : 

FName2()  : named(false)  {} 

FName2 (const  strings  fname) 

: if stream (fname . c_str 0) , fileName (fname)  { 
assure (*this,  fileName); 
named  = true; 

} 

string  name()  const  { return  fileName;  } 
void  name (const  strings  newName)  { 

if (named)  return;  //  Don't  overwrite 
fileName  = newName; 
named  = true; 


}; 


int  main  ( ) { 

FName2  f ile ( "FName2 . cpp" ) ; 

assure (file,  "FName2 . cpp" ) ; 

cout  <<  "name:  " <<  f ile. name ()  <<  endl; 

string  s; 

getline (f ile,  s);  //  These  work  too! 
file . seekg (-200,  ios::end); 
file . close  ( ) ; 

} ///:- 
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Now  any  mennber  function  availablefor  an  if  stream  object  is 
avail  able  for  an  FName2object.  You  can  also  see  that  non-mennber 
functions  I ikegetline(  )that  expect  an  ifstreamcan  also  work  with 
an  FN  ame2  That's  because  an  FN  ame2/s  a type  of  ifstreairi  it 
doesn't  simply  contain  one.  This  isa  very  important  issuethat  will 
be  explored  at  the  end  of  this  chapter  and  in  the  next  one. 

private  inheritance 

You  can  inherit  a base  cl  ass  privately  by  leaving  off  thepublicin 
the  base-class  list,  or  by  explicitly  saying  private( probably  a better 
policy  because  it  is  clear  to  the  user  that  you  mean  it).  When  you 
inherit  privately,  you're  "implementing  in  terms  of;"  that  is,  you're 
creating  a new  cl  ass  that  has  all  of  the  data  and  functionality  of  the 
base  cl  ass,  but  that  functionality  is  hidden,  so  it's  only  part  of  the 
underlyi  ng  i mplementation.  The  class  user  has  no  access  to  the 
underlying  functionality,  and  an  object  cannot  be  treated  as  a 
i nstance  of  the  base  class  (as  it  was  i n FN  ame2.cp(^. 

You  may  wonder  what  the  purpose  of  private!  nheritance  is, 
because  the  alternative  of  using  composition  to  create  a private 
object  in  the  new  cl  ass  seems  more  appropriate,  private!  nheritance 
is  included  in  the  language  for  completeness,  but  if  for  no  other 
reason  than  to  reduce  confusion,  you'll  usually  want  to  use 
composition  rather  than  private! nheritance.  However,  there  may 
occasionally  be  situations  where  you  want  to  produce  part  of  the 
same  i nterface  as  the  base  cl  ass  and  d i sal  I ow  the  treatment  of  the 
object  as  if  it  were  a base-class  object,  private!  nheritance  provides 
this  ability. 

Publicizing  privately  inherited  members 

When  you  inherit  privately,  all  thepublicmembersof  thebase 
class  become  private  If  you  want  any  of  them  to  bevisible,  just  say 
their  names  (no  arguments  or  return  values)  in  thepublicsection  of 
the  derived  class: 

I //:  C14 : Privateinheritance . cpp 
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class  Pet  { 
public : 

char  eat()  const  { return  'a';  } 

int  speak  0 const  { return  2;  } 

float  sleepO  const  { return  3.0;  } 

float  sleep  (int)  const  { return  4.0;  } 


class  Goldfish  : Pet  { //  Private  inheritance 
public : 

Pet:: eat;  //  Name  publicizes  member 

Pet:: sleep;  //  Both  overloaded  members  exposed 


int  main  ( ) { 

Goldfish  bob; 
bob . eat  ( ) ; 
bob . sleep  ( ) ; 
bob . sleep  ( 1 ) ; 

//!  bob . speak  0; //  Error:  private  member  function 
} ///:- 

Thus,  privateinheritance  is  useful  if  you  want  to  hide  part  of  the 
functionality  of  the  base  class. 

Noticethat  giving  the  name  of  an  overloaded  function  exposes  all 
the  versions  of  the  overloaded  function  in  the  base  class. 

You  should  think  carefully  before  using  privateinheritance  instead 
of  composition;  privateinheritance  has  particular  complications 
when  combined  with  runtime  type  identification  (this  is  the  topic  of 
a chapter  in  Volume  2 of  this  book,  down  load  able  from 
www.BruceEckd.com). 


protected 

Now  that  you've  been  introduced  to  inheritance,  the  keyword 
protectedfinally  has  meaning.  In  an  ideal  world,  privatemembers 
would  always  be  hard-and-fast  private  but  in  real  projects  there 
are  times  when  you  want  to  make  something  hidden  from  the 
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world  at  large  and  yet  allow  access  for  mennbers  of  derived  classes. 
The  protected  keyword  is  a nod  to  pragmatism;  it  says,  "This  is 
pri  vateas  far  as  the  cl  ass  user  i s concerned,  but  avai  I abl  e to  anyone 
who  inheritsfrom  this  class." 

The  best  approach  is  to  leave  the  data  members  private-  you 
should  always  preserve  your  right  to  change  the  underlying 
implementation.  You  can  then  allow  controlled  access  to  inheritors 
of  your  class  through  protected  member  functions: 

//:  C14 :Protected. cpp 
//  The  protected  keyword 
#include  <fstream> 
using  namespace  std; 

class  Base  { 
int  i ; 
protected : 

int  readO  const  { return  i;  } 
void  set (int  ii)  { i = ii;  } 
public : 

Base  (int  ii  = 0)  : i(ii)  {} 

int  value (int  m)  const  { return  m*i;  } 

}; 


class  Derived  : public  Base  { 
int  j ; 
public : 

Derived(int  jj  = 0)  : j(jj)  {} 

void  change (int  x)  { set  (x) ; } 

}; 


int  main  ( ) { 

Derived  d; 
d. change  (10)  ; 

} ///:- 

You  will  find  examples  of  the  need  for  protectedin  examples  later 
in  this  book,  and  in  Volume  2. 


642 


Thinking  in  C+  + 


www.BruceEckel.com 


protected  inheritance 

When  you're  inheriting,  the  base  class  defaults  to  private  which 
means  that  al  I of  the  pubi  ic  member  functions  are  privateto  the 
user  of  the  new  class.  Normally,  you'll  makethe  inheritance  public 
so  the  i nterface  of  the  base  cl  ass  i s al  so  the  i nterface  of  the  d eri  ved 
class.  However,  you  can  also  usetheprotectedkeyword  during 
inheritance. 

Protected  derivation  means "implemented-in-terms-of"  toother 
classes  but  "is-a"  for  derived  classes  and  friends.  It's  something 
you  don't  use  very  often,  but  it's  in  the  language  for  completeness. 


Operator  overloading  & inheritance 

Except  for  the  assi  gn  ment  operator,  operators  are  automati  cal  I y 
inherited  into  a derived  class.  Thiscan  be  demonstrated  by 
inheriting  from  C 12:Byte.h 

//:  C14 : Operatorinheritance . cpp 
//  Inheriting  overloaded  operators 
#include  " . . /C12/Byte . h" 

#include  <fstream> 
using  namespace  std; 
ofstream  out ( "ByteTest . out " ) ; 

class  Byte2  : public  Byte  { 
public : 

//  Constructors  don't  inherit: 

Byte2 (unsigned  char  bb  = 0 ) : Byte (bb)  {} 

//  operator=  does  not  inherit,  but 

//  is  synthesized  for  memberwise  assignment. 

//  However,  only  the  SameType  = SameType 
//  operator=  is  synthesized,  so  you  have  to 
//  make  the  others  explicitly: 

Byte2&  operator=  (const  Byte&  right)  { 

Byte : : ope rat or = (right ) ; 
return  *this; 

} 

Byte2&  operator= ( int  i)  { 

Byte : : ope rat or = ( i ) ; 
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return  *this; 


} 


}; 


//  Similar  test  function  as  in  C12 : ByteTest . cpp : 
void  k(Byte2&  bl,  Byte2&  b2)  { 

bl  = bl  * b2  + b2  % bl; 

#define  TRY2 (OP)  \ 

out  <<  "bl  = bl . print (out ) ; \ 
out  <<  ",  b2  = b2 . print (out ) ; \ 
out  <<  bl  " #0P  " b2  produces  \ 

(bl  OP  b2 ). print (out ) ; \ 
out  <<  endl; 

bl  = 9;  b2  = 47; 

TRY2(+)  TRY2(-)  TRY2(*)  TRY2(/) 

TRY2(%)  TRY2(^)  TRY2(&)  TRY2 ( | ) 

TRY2(<<)  TRY2(>>)  TRY2 (+=)  TRY2 (-=) 

TRY2(*=)  TRY2(/=)  TRY2 (%=)  TRY2(^=) 

TRY2(&=)  TRY2(|=)  TRY2 (>>=)  TRY2 (<<=) 

TRY2 (=)  //  Assignment  operator 

//  Conditionals: 

#define  TRYC2 (OP)  \ 

out  <<  "bl  = ";  bl . print (out ) ; \ 
out  <<  ",  b2  = ";  b2 . print (out ) ; \ 
out  <<  ";  bl  " #0P  " b2  produces  ";  \ 
out  <<  (bl  OP  b2 ) ; \ 

out  <<  endl; 

bl  = 9;  b2  = 47; 

TRYC2(<)  TRYC2(>)  TRYC2 (==)  TRYC2(!=)  TRYC2 (<=) 

TRYC2(>=)  TRYC2(&&)  TRYC2 ( | | ) 

//  Chained  assignment: 

Byte2  b3  = 92; 
bl  = b2  = b3; 


int  main  ( ) { 

out  <<  "member  functions:"  <<  endl; 
Byte2  bl (47) , b2 (9) ; 
k(bl,  b2); 

} ///:- 
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The  test  code  is  identical  to  that  in  C 12:ByteTest.cppexcept  that 
Byte2  i s used  i nstead  of  Byte  Thi  s way  al  I the  operators  are 
verified  to  work  with  Byte2vi a inheritance. 

When  you  examine  the  cl  ass  Byte2  you'll  see  that  the  constructor 
must  be  explicitly  defined,  and  that  only  the operator=that  assigns 
a Byte2to  a Byte2 is  synthesized;  any  other  assignment  operators 
that  you  need  you'll  have  to  synthesize  on  your  own. 


Multiple  inheritance 

You  can  inheritfrom  one  cl  ass,  so  itwould  seem  to  makesenseto 
inherit  from  more  than  one  cl  ass  at  a time.  Indeed  you  can,  but 
whether  it  makes  sense  as  part  of  a desi gn  i s a su bject  of  conti  nu i ng 
debate.  One  thing  is  generally  agreed  upon:  You  shouldn't  try  this 
until  you've  been  programming  quiteawhileand  understand  the 
language  thoroughly.  By  that  time,  you'll  probably  realize  that  no 
matter  how  much  you  think  you  absolutely  must  use  multiple 
inheritance,  you  can  almost  always  get  away  with  single 
inheritance. 

Initially,  multipleinheritance  seems  si  mpleenough:  You  add  more 
classes  in  the  base-class  list  during  inheritance,  separated  by 
commas.  However,  multiple  inheritance  introduces  a number  of 
possibilities  for  ambiguity,  which  is  why  a chapter  in  Volume2  is 
devoted  to  the  subject. 


I ncremental  development 

Oneof  the  advantages  of  inheritance  and  composition  is  that  these 
support  incremental  d&/elopment  by  allowing  you  to  introduce  new 
code  without  causing  bugs  in  existing  code.  If  bugs  do  appear,  they 
are  isolated  within  the  new  code.  By  inheriting  from  (or  composing 
with)  an  existing,  functional  class  and  adding  data  members  and 
member  functions  (and  redefining  existing  member  functions 
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during  inheritance)  you  leave  the  existing  code-  that  someone  else 
may  still  be  using  - untouched  and  unbugged.  If  a bug  happens, 
you  know  it's  in  your  new  code,  which  is  much  shorter  and  easier 
to  read  than  if  you  had  modified  the  body  of  existing  code. 

It's  rather  amazing  how  cleanly  the  classes  are  separated.  You  don't 
even  need  the  source  code  for  the  member  functions  in  order  to 
reuse  the  code,  just  the  header  f i I e descri  bi  ng  the  cl  ass  and  the 
object  fileor  library  file  with  the  compiled  member  functions.  (This 
istruefor  both  inheritance  and  composition.) 

It's  important  to  realize  that  program  development  isan 
incremental  process,  just  like  human  learning.  You  can  do  as  much 
analysis  as  you  want,  but  you  still  won't  know  all  the  answers 
when  you  set  out  on  a project.  You'll  have  much  more  success - 
and  more  immediate  feed  back  - if  you  start  out  to  "grow"  your 
project  as  an  organic,  evolutionary  creature,  rather  than 
constructing  it  all  atoncelikeaglass-boxskyscraper2. 

Although  inheritance  for  experimentation  is  a useful  technique,  at 
some  point  after  things  stabilize  you  need  to  take  a new  look  at 
your  class  hierarchy  with  an  eyeto  collapsing  it  into  a sensible 
structure^.  Remember  that  underneath  it  all,  inheritance  is  meant  to 
express  a relationship  that  says,  "This  new  class  is  a type  of  that  old 
class."  Your  program  should  not  be  concerned  with  pushing  bits 
around,  but  instead  with  creating  and  manipulating  objects  of 
varioustypesto  express  a model  in  the  terms  given  you  from  the 
problem  space. 


2 To  learn  more  about  this  idea,  see  Extreme  Programming  Exp/a/ned,  by  Kent  Beck 
(Addison-Wesley  2000). 

^ See  Refactoring:  Improving  theDesign  of  Existing  Code  by  Martin  Fowler  (Addison- 
Wesley  1999). 
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Upcasting 

Earlier  in  the  chapter,  you  saw  how  an  object  of  a class  derived 
from  i f stream  has  all  the  character!  sties  and  behaviors  of  an 
if  stream  object.  In  FName2.cpp  any  if  stream  member  function 
could  be  cal  led  for  an  FN  ame2object. 

The  most  I mportant  aspect  of  inheritance  is  not  that  it  provides 
member  functions  for  the  new  class,  however.  It's  the  relationship 
expressed  between  the  new  class  and  the  base  class.  This 
relationship  can  be  summarized  by  saying,  "The  new  cl  ass /s  a type 
of  the  existing  class." 

This  description  is  notjust  a fanciful  way  of  explaining  inheritance 
- it's  supported  directly  by  the  compiler.  As  an  example,  consider  a 
base  cl  ass  cal  led  I nstrumentthat  represents  musical  instruments 
and  a derived  class  called  Wind.  Because  inheritance  means  that  all 
the  f u ncti  ons  i n the  base  cl  ass  are  al  so  avai  I abl  e i n the  d eri  ved  cl  ass, 
any  message  you  can  send  to  the  base  class  can  also  be  sent  to  the 
derived  class.  So  ifthelnstrumentclasshasaplay(  )member 
function,  so  will  Wind  instruments.  This  means  we  can  accurately 
say  that  a Wind  object  is  also  a type  of  i nstrumentThefol  lowing 
example  shows  how  the  compiler  supports  this  notion: 

//:  C14 : Instrument . epp 
//  Inheritance  & upcasting 

enum  note  { middleC,  Csharp,  Cflat  };  //  Etc. 

class  Instrument  { 
public : 

void  play (note)  const  {} 

}; 


//  Wind  objects  are  Instruments 
//  because  they  have  the  same  interface: 
class  Wind  : public  Instrument  { } ; 

void  tune (Instruments  i)  { 

//  . . . 

i . play (middleC) ; 
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int  main  ( ) { 

Wind  flute; 

tune  (flute);  //  Upcasting 

} III-.- 

What's  interesting  in  thisexampieisthetune(  )function,  which 
accepts  an  Instrumentreference.  However,  in  main(  )thetune( ) 
function  iscaiied  by  handing  it  a reference  to  a Wind  object.  Given 
that  C++ is  very  parti cuiar  about  type  checking,  itseenns  strange 
that  a function  that  accepts  one  type  wiii  readiiy  accept  another 
type,  untii  you  reaiizethat  a Wind  object  is  aiso  an  Instrument 
object,  and  there's  no  function  thattune(  )couid  caii  for  an 
Instrumentthat  isn't  aiso  in  Wind  (this  is  what  inheritance 
guarantees).  insidetune( ) the  code  works  for  I nstrumentand 
anythi  ng  derived  from  I nstrument  and  the  act  of  converti  ng  a 
Wind  reference  or  pointer  into  an  Instrumentreference  or  pointer 
iscaiied  upcasting. 

Why  "upcasting?" 

The  reason  for  the  term  is  historicai  and  is  based  on  the  way  dass 
inheritance  diagrams  have  trad  itionaiiy  been  drawn:  with  the  root 
at  the  top  of  the  page,  growing  downward.  (Of  course,  you  can 
draw  your  diagrams  any  way  you  find  heipfui.)  The  inheritance 
diagram  for  I nstrument.cppis  then: 


Casting  from  derived  to  base  moves  up  on  the  inheritance  diagram, 
so  it'scommoniy  referred  to  as  upcasting.  Upcasting  isaiwayssafe 
because  you're  going  from  a more  specific  type  to  a moregenerai 
type  - the  oniy  thing  that  can  occur  to  the  dass  interface  is  that  it 
can  i ose  member  fu ncti ons,  not  gai  n them.  Thi s i s why  the  compi  i er 
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allows  upcasting  without  any  ©cplicit  casts  or  other  special 
notation. 


Upcasting  and  the  copy-constructor 

If  you  al  low  the  compi  ler  to  synthesize  a copy-constructor  for  a 
derived  class,  it  will  automatically  call  the  base-class  copy- 
constructor,  and  then  the  copy-constructors  for  all  the  member 
objects  (or  perform  a bitcopy  on  bui  It-i  n types)  so  you'l  I get  the 
right  behavior: 

//:  C14 : CopyConstructor . cpp 

//  Correctly  creating  the  copy-constructor 
#include  <iostream> 
using  namespace  std; 


class  Parent  { 
int  i ; 
public : 

Parent (int  ii)  : i(ii)  { 

cout  <<  "Parent  (int  ii)\n"; 

} 

Parent  (const  Parents  b)  : i(b.i)  { 
cout  <<  "Parent (const  Parents) \n"; 

} 

Parent  0 : i(0)  { cout  <<  "Parent  () \n" ; } 

friend  ostreamS 

operator<< (ostreamS  os,  const  Parents  b)  { 
return  os  <<  "Parent:  " <<  b.i  <<  endl; 


}; 


class  Member  { 
int  i ; 
public : 

Member (int  ii)  : i(ii)  { 

cout  <<  "Member (int  ii)\n"; 

} 

Member (const  Members  m)  : i(m.i)  { 
cout  <<  "Member (const  Members) \n"; 

} 

friend  ostreamS 

operator<< (ostreamS  os,  const  Members  m)  { 
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return  os  <<  "Member: 


<<  m . i <<  endl ; 


} 


}; 


class  Child  : public  Parent  { 
int  1 ; 

Member  m; 
public : 

Child(int  11)  : Parent(ii),  1(11),  m(ii)  { 

cout  <<  "Child(int  11) \n"; 

} 

friend  ostream& 

operator<< (ostream&  os,  const  Child&  c)  { 
return  os  <<  (Parents)  c <<  c.m 

<<  "Child:  " <<  c.i  <<  endl; 


}; 


int  main  ( ) { 

Child  c (2 ) ; 

cout  <<  "calling  copy-constructor:  " <<  endl; 

Child  c2  = c;  //  Calls  copy-constructor 
cout  <<  "values  in  c2:\n"  <<  c2; 

} ///:- 

Theoperator«for  Child  is  interesting  becauseof  the  way  that  it 
cai  is  the  operator«for  the  Parentpart  within  it:  by  casting  the 
Chi  Id  object  to  a Parents  (if  you  cast  to  a base-ci  ass  ob/'ect  instead 
of  a reference  you  wiii  usuaiiy  get  undesirabie  resuits): 

return  os  <<  (Parents) c <<  c.m 

Sincethecompiierthen  sees  it  as  a Parent  it  cai  is  the  Parent 
version  of  operator« 

You  can  seethat  Child  has  no  expiicitiy-defined  copy-constructor. 
The  compiier  then  synthesizes  the  copy-constructor  (si  nee  that  is 
oneof  the  four  functions  it  wiii  synthesize,  aiong  with  thedefauit 
constructor  - if  you  don't  create  any  constructors  - the  operator= 
and  the  destructor)  by  caiiing  the  Parentcopy-constructor  and  the 
M ember  copy-constructor.  This  is  shown  in  the  output 
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Parent  ( int  ii ) 

Member (int  ii) 

Child(int  ii) 

calling  copy-constructor: 

Parent  (const  Parents) 

Member (const  Members) 
values  in  c2 : 

Parent : 2 
Member:  2 
Child:  2 

However,  if  you  try  to  write  your  own  copy-construrtor  for  Child 
an(d  you  make  an  innocent  mistake  and  do  it  badly: 

Child(const  Childs  c)  : i(c.i),  m(c.m)  {} 

then  the  defau/t  constructor  will  automatically  be  called  for  the 
base-class  part  of  Child,  si  nee  that's  what  the  compiler  falls  back  on 
when  it  has  no  other  choice  of  constructor  to  call  (remember  that 
some  constructor  must  always  be  called  for  every  object,  regardless 
of  whether  it's  a subobject  of  another  class).  The  output  will  then 
be: 


Parent  ( int  ii ) 

Member (int  ii) 

Child(int  ii) 

calling  copy-constructor: 

Parent  ( ) 

Member (const  Members) 
values  in  c2 : 

Parent : 0 
Member:  2 
Child:  2 

This  is  probably  not  what  you  expect,  si  nee  generally  you'll  want 
the  base-class  portion  to  be  copied  from  the  exist!  ng  object  to  the 
new  object  as  part  of  copy-construction. 

To  repair  the  problem  you  must  remember  to  properly  call  the 
base-class  copy-constructor  (as  the  compi  ler  does)  whenever  you 
write  your  own  copy-constructor.  This  can  seema  littlestrange- 
looking  at  first  but  it's  another  example  of  upcasting: 
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Child(const  Child&  c) 

: Parent  (c)  , i(c.i),  m(c.in)  { 
cout  <<  "Child (Child& ) \n" ; 

} 

The  Strange  part  is  where  the  Parentcopy-constructor  is  called: 
Parent(c)  What  does  it  mean  to  pass  a C hi  Id  object  to  a Parent 
constructor?  But  Child  is  inherited  from  Parent  so  a Child 
reference  is  a Parentreference.  The  base-class  copy-constructor  call 
upcasts  a reference  to  Chi  Id  to  a reference  to  Parentand  uses  itto 
perform  the  copy-construction.  When  you  write  your  own  copy 
constructors  you'l  I almost  always  want  to  do  the  same thi  ng. 

Composition  vs.  inheritance  (revisited) 

Oneof  the  dearest  ways  to  determine  whether  you  should  be  using 
composition  or  inheritance  is  by  asking  whether  you'll  ever  need  to 
upcast  from  your  new  class.  Earlier  in  this  chapter,  the  Stack  cl  ass 
was  specialized  using  inheritance.  However,  chances  are  the 
StringStackobjects  will  be  used  only  as  string  containers  and 
never  upcast,  so  a more  appropriate  alternative  is  composition: 

//:  C14 : InheritStack2 . cpp 
//  Composition  vs.  inheritance 
#include  " . . /CO 9/Stack4 . h" 

#include  ".. /require . h" 

#include  <iostream> 

#include  <fstream> 

#include  <string> 
using  namespace  std; 

class  StringStack  { 

Stack  stack;  //  Embed  instead  of  inherit 
public : 

void  push (string*  str)  { 
stack . push ( str)  ; 

} 

string*  peek()  const  { 

return  ( string* ) stack . peek ()  ; 

} 

string*  pop ( ) { 

return  ( string* ) stack . pop () ; 


652 


Thinking  in  C-I--I- 


www.BruceEckel.com 


} 


}; 


int  main  ( ) { 

if stream  in  ( " Inherit St ack2 . cpp" ) ; 
assure (in,  " Inherit St ack2 . cpp" ) ; 
string  line; 

StringStack  textlines; 
while (getline (in,  line)) 

textlines . push (new  string  (line) ) ; 
string*  s; 

while((s  = textlines . pop ( ) ) !=  0)  //  No  cast! 

cout  <<  *s  <<  endl; 

} ///:- 

The  file  is  i(dentical  to  lnheritStack.cppexcept  that  a Stack  objert  is 
embed(de(d  in  StringStack  an(j  mennber  functions  are  cal  I e(d  for  the 
embedded  object.  There's  still  no  time  or  space  overhead  because 
the  subobject  takes  up  the  same  amount  of  space,  and  all  the 
additional  type  checking  happens  at  compile  time. 

Although  ittendsto  be  more  confusing,  you  could  also  use  private 
inheritanceto  express  "implemented  in  terms  of."  This  would  also 
solve  the  problem  adequately.  One  place  it  becomes  i mportant, 
however,  is  when  multi  pie  inheritance  might  be  warranted.  In  that 
case,  if  you  see  a design  in  which  composition  can  be  used  instead 
of  inheritance,  you  may  be  able  to  eliminate  the  need  for  multiple 
inheritance. 

Pointer  & reference  upcasting 

In  instrumentcppthe  upcasting  occurs  during  the  function  call  - a 
Wind  object  outside  the  function  has  its  reference  taken  and 
becomes  an  Instrumentreferenceinsidethe  function.  Upcasting 
can  also  occur  during  a simple  assignment  to  a pointer  or  reference: 

Wind  w; 

Instrument*  ip  = &w;  //  Upcast 
Instruments  ir  = w;  //  Upcast 
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Like  the  function  call,  neither  of  these  cases  requires  an  explicit 
cast. 

A crisis 

Of  course,  any  upcast  loses  type  infornnation  about  an  object.  If  you 
say 

Wind  w; 

Instrument*  ip  = &w; 

the  compiler  can  deal  with  ip  only  as  an  Instrumentpointer  and 
nothing  else.  That  is,  it  cannot  know  that  ip  actually  happens  to 
point  to  a Wind  object.  So  when  you  call  thepiay( ) member 
function  by  saying 

I ip->play (middleC) ; 

the  compiler  can  know  only  that  it's  calling  piay(  )for  an 
Instrumentpointer,  and  call  the  base-class  version  of 
lnstrument::play(  instead  of  what  it  should  do,  which  iscall 
Wind::play(  )Thus,  you  won't  get  the  correct  behavior. 

This  is  a significant  problem;  it  is  solved  in  Chapter  15  by 
introducing  the  third  cornerstone  of  object-oriented  programming: 
polymorphism  (implemented  in  C-H-with  virtual  functions). 


Summary 

Both  inheritance  and  composition  allow  you  to  create  a new  type 
from  existing  types,  and  both  embed  subobjects  of  the  existing 
types  inside  the  new  type.  Typically,  however,  you  use 
composition  to  reuse  existing  types  as  part  of  the  underlying 
implementation  of  the  new  type  and  inheritance  when  you  want  to 
force  the  new  type  to  be  the  same  type  as  the  base  cl  ass  (type 
equ  i val  ence  guarantees  i nterface  equ  i val  ence).  Si  nee  the  deri  ved 
class  has  the  base-class  interface,  it  can  be  upcast  to  the  base,  which 
is  critical  for  polymorphism  as  you'll  see  in  Chapter  15. 
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Although  code  raj se through  composition  and  inheritance  is  very 
helpful  for  rapid  project  development,  you'll  generally  want  to 
redesign  your  class  hierarchy  before  allowing  other  programmers 
to  become  dependent  on  it.  Your  goal  Isa  hierarchy  in  which  each 
class  has  a specific  use  and  is  neither  too  big  (encompassing  so 
much  functionality  that  it's  unwieldy  to  reuse)  nor  annoyingly 
small  (you  can't  use  it  by  itself  or  without  adding  functionality). 


Exercises 

Solutions  to  selected  exercises  can  be  found  in  the  electronic  document  TheThinking  in  C++ Annotated 
Solution  Guide,  aval  I able  for  a small  feefromwww.BruceEckel.com. 

1.  Modify  Cancppso  that  it  also  inherits  from  a class  cal  led 
Vehicle  placing  appropriate  member  functions  in 
Vehicle(that  is,  makeup  some  member  functions).  Add 
a nondefault  constructor  to  Vehicle  which  you  must  call 
i nsi  de  C ai^s  constructor. 

2.  Createtwoclasses,  A and  B,with  default  constructors 
that  announce  themselves.  Inherit  a new  class  called  C 
from  A,  and  create  a member  object  of  B in  C,  but  do  not 
create  a constructor  for  C . Create  an  object  of  class  C and 
observe  the  results. 

3.  Create  a three- level  hierarchy  of  classes  with  default 
constructors,  along  with  destructors,  both  of  which 
announce  themselves  to  cout  Verify  that  for  an  object  of 
the  most  derived  type,  all  three  constructors  and 
destructors  are  automatically  called.  Explain  the  order  in 
which  the  cal  Is  are  made. 

4.  Modify  Combined.cppto  add  another  level  of 
inheritance  and  a new  member  object.  Add  codeto  show 
when  the  constructors  and  destructors  are  being  called. 

5.  In  Combined  .cpp  create  a class  D that  inherits  from  B 
and  has  a member  object  of  class C.  Add  codeto  show 
when  the  constructors  and  destructors  are  being  called. 
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6.  Modify  Order .cppto  add  another  level  of  inheritance 
DerivedSwith  mennber  objects  of  class  M ember4and 
M embers  T race  the  output  of  the  program. 

7.  In  NameHiding.cppverify  that  in  Derived2  Derived3 
and  Derived4  none  of  the  base-class  versions  of  f(  )are 
available. 

8.  Modify  NameHiding.cppby  adding  three  overloaded 
functions  named  h(  )to  Base  and  show  that  redefining 
one  of  them  in  a derived  class  hides  the  others. 

9 . I nheri  t a cl  ass  Stri  ngV  ectoif  rom  vector<void*>end 
redefine  the  push_back(  )and  operator[]member 
functions  to  accept  and  produce  string*.  What  happens  if 
you  try  to  push_back(  }a  void*? 

10.  Write  a cl  ass  containing  a iong  and  usethepsuedo- 
constructor  call  syntax  in  the  constructor  to  initialize  the 
iong 

11.  C reate  a cl  ass  cal  I ed  A steroid  U se  i nheritance  to 
specializethePStashclass  in  Chapter  13(PStash.h& 
PStash.cpF)  so  that  it  accepts  and  returns  Asteroid 
pointers.  Also  modify  PStashTestcppto  test  your 
classes.  Change  the  class  so  PStash  is  a member  object. 

12.  Repeat  Exercise  11  with  a vector  in  stead  of  a PStash 

13.  In  SynthesizedFunctions.cppmodify  Chesstogiveita 
default  constructor,  copy-constructor,  and  assignment 
operator.  Demonstrate  that  you've  written  these 
correctly. 

14.  Create  two  classes  called  T raveierand  Pagerwithout 
default  constructors,  but  with  constructors  that  take  an 
argument  of  type  string  which  they  simply  copy  to  an 
internal  string  variable.  For  each  class,  write  the  correct 
copy-constructor  and  assignment  operator.  Now  inherit  a 
class  Business! raveieifrom  T raveierand  give  it  a 
member  object  of  type  Pager.  Write  the  correct  default 
constructor,  a constructor  that  takes  a string  argument,  a 
copy-constructor,  and  an  assignment  operator. 
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15.  Create  a class  with  two  staticmember  functions.  Inherit 
from  thi  s cl  ass  and  redefi  ne  one  of  the  member  fu  ncti  ons. 
Show  that  the  other  is  hidden  in  the  derived  class. 

16.  Lookup  moreof  the  member  functions  for  if  stream  In 
FN  ame2.cpp  try  them  out  on  the  file  object. 

17.  Useprivateand  protectedinheritanceto  createtwo  new 
classes  from  a base  class.  Then  attempt  to  upcast  objects 
of  the  derived  cl  ass  to  the  base  cl  ass.  Explain  what 
happens. 

18.  In  Protected .cpp add  a member  function  in  Derivedthat 
cal  Is  the  protectedBase  member  read( ) 

19.  ChangeProtected.cppsothatDerivedisusing  protected 

inheritance.  See  if  you  can  call  value(  )for  a Derived 
object. 

20.  Create  a cl  ass  cal  led  SpaceShipwith  afly(  )method. 
InheritShuttlefromSpaceShipand  add  aland( ) 

method.  Create  a new  Shuttle  upcast  by  pointer  or 
referenceto  a Spaceship  and  try  to  cal  I theland( ) 
method.  Explain  the  results. 

21.  M od  ify  I nstrumentcppto  add  a prepare!  )method  to 
Instrument  Cal  I prepare!  )insi  detune! ) 

22.  Modify  I nstrument.cppso  that  play! ) prints  a message 
tocout  and  Wind  redefines  pi  ay!  )to  print  a different 
message  to  cout  Run  the  program  and  explain  why  you 
probably  wouldn't  want  this  behavior.  Now  put  the 
virtual  keyword  (which  you  will  learn  about  in  Chapter 
15)  in  front  of  the  pi  ay!  )declaration  in  Instrumentand 
observe  the  change  in  the  behavior. 

23.  In  CopyConstructor.cppinherita  new  class  from  Child 
and  give  it  a M emberm.  Write  a proper  constructor 
copy-con  structoroperators  and  operator«for 
ostreams,  and  test  the  cl  ass  in  main! ) 

24.  Take  the  exampleCopyConstructor.cppand  modify  it  by 
adding  your  own  copy-constructor  to  Child  without 
calling  the  base-class  copy-constructor  and  see  what 
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happens.  Fix  the  problem  by  making  a proper  explicit 
call  to  the  base-class  copy  constructor  in  theconstructor- 
i ni ti  al  I zer  I i St  of  the  C h i I d copy-constructor. 

25.  Modify  I nheritStack2.cppto  usea  vector<string> 
instead  of  a Stack 

26.  Create  a cl  ass  Rock  with  a default  constructor,  a copy- 
constructor,  an  assignment  operator,  and  a destructor,  all 
of  which  announce  to  coutthat  they've  been  called.  In 
main( ) create  a vector<Rock>(that  is,  hold  Rock  objects 
by  value)  and  add  some  Rocks.  Run  the  program  and 
explai  n the  output  you  get.  N ote  whether  the  destructors 
are  cal  led  for  the  Rock  objects  in  the  vector.  Now  repeat 
the  exercise  with  a vector<Rock*>ls  it  possibleto  create 
a vector<Rock& 

27.  This  exerd se  creates  the  d esi gn  pattern  cal  I ed  proxy.  Start 
with  a base  class  Subjectand  give  it  three  functions:  f( ), 
g( ),  and  h( ).  Now  inherit  a class  Proxy  and  two  classes 
Implementationland  lmplementation2Trom  Subject 
Proxy  should  contain  a pointer  to  a Subject  and  all  the 
member  functions  for  Proxy  should  just  turn  around  and 
make  the  same  cal  I s through  the  Subjectpoi  nter.  The 
Proxy  constructor  takes  a poi  nter  to  a Subjectthat  is 
installed  in  the  Proxy  (usually  by  the  constructor).  In 
main( ) create  two  different  Proxy  objects  that  use  the 
two  different  implementations.  Now  modify  Proxy  so 
that  you  can  dynamically  change  implementations. 

28.  M od  ify  A rrayO  peratorN  ew  .cp(f  rom  C hapter  13  to 
show  that,  if  you  inherit  from  Widget  the  allocation  still 
works  correctly.  Explain  why  inheritance  in  Framis.cpp 
from  Chapter  13  would  not  work  correctly. 

29.  M odify  Framis.cppfrom  Chapter  13  by  inheriting  from 
Framisand  creating  new  versions  of  new  and  deletefor 
your  derived  class.  Demonstrate  that  they  work  correctly. 
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15:  Polymorphism  & 
Virtual  Functions 

Polymorphism  (implemented  in  C++  with  virtual  ^ 
functions)  is  the  third  essential  feature  of  an  object- 
oriented  programming  language,  after  data  abstraction 
and  inheritance. 
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It  provides  another  dimension  of  separation  of  i nterface from 
implementation,  to  decouplew/iatfrom  how.  Polymorphism  allows 
improved  code  organization  and  readability  as  well  as  the  creation 
of  e)ctens/We  programs  that  can  be"grown"  not  only  during  the 
original  creation  of  the  project,  but  also  when  new  features  are 
desired. 

Encapsulation  creates  new  data  types  by  combining  characteristics 
and  behaviors.  Access  control  separates  the  interface  from  the 
implementation  by  making  the  details  private  This  kind  of 
mechanical  organization  makes  ready  sense  to  someone  with  a 
procedural  programming  background.  But  virtual  functions  deal 
with  decoupling  in  terms  of  types.  In  Chapter  14,  you  saw  how 
inheritance  allows  the  treatment  of  an  object  as  its  own  type  or  its 
base  type.  This  ability  is  critical  because  it  allows  many  types 
(derived  from  the  same  base  type)  to  be  treated  as  if  they  were  one 
type,  and  asinglepieceof  code  to  work  on  all  those  different  types 
equally.  The  virtual  function  allows  one  type  to  express  its 
distinction  from  another,  similar  type,  as  long  as  they're  both 
derived  from  thesamebasetype.  This  distinction  is  expressed 
through  differences  in  behavior  of  the  functions  that  you  can  call 
through  the  base  class. 

In  this  chapter,  you'll  learn  about  virtual  functions,  starting  from 
thebasicswith  simple  examples  that  strip  away  everything  but  the 
"virtual ness"  of  the  program. 


Evolution  of  C++  programmers 

C programmers  seem  to  acquire  C++ in  three  steps.  First,  as  simply 
a "better  C,"  because  C++ forces  you  to  declare  all  functions  before 
using  them  and  is  much  pickier  about  how  variables  are  used.  You 
can  often  find  the  errors  in  a C program  simply  by  compiling  it 
with  a C++ compiler. 
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The  second  step  is  "object- based"  C-H-.  This  means  that  you  easily 
seethe  code  organization  benefits  of  group!  ng  a data  structure 
together  with  the  functions  that  act  upon  it,  the  value  of 
constructors  and  destructors,  and  perhaps  some  simple  inheritance. 
Most  programmers  who  have  been  working  with  C for  a while 
quickly  see  theusefulness  of  this  because,  whenever  they  createa 
library,  this  is  exactly  what  they  try  to  do.  With  C-H-,  you  have  the 
aid  of  the  compiler. 

You  can  get  stuck  at  the  object-based  level  because  you  can  quickly 
get  there  and  you  get  a lot  of  benefit  without  much  mental  effort. 
It's  also  easy  to  feel  I ike  you're  creati  ng  data  types  - you  make 
classes  and  objects,  you  send  messages  to  those  objects,  and 
everything  is  nice  and  neat. 

But  don't  befooled.  If  you  stop  here,  you're  missing  out  on  the 
greatest  part  of  the  language,  which  is  the  jump  to  true  object- 
oriented  programming.  You  can  do  this  only  with  virtual  functions. 

Virtual  functions  enhancethe  concept  of  type  instead  of  just 
encapsulating  code  inside  structures  and  behind  walls,  so  they  are 
without  a doubt  the  most  difficult  concept  for  the  new  C-H- 
programmer  to  fathom.  However,  they're  also  the  turning  point  in 
the  understanding  of  object-oriented  programming.  If  you  don't 
use  virtual  functions,  you  don't  understand  OOP  yet. 

Because  the  virtual  function  is  intimately  bound  with  the  concept  of 
type,  and  type  is  at  the  core  of  object-oriented  programming,  there 
is  no  analog  to  the  virtual  function  in  atraditional  procedural 
language.  As  a procedural  programmer,  you  have  no  referent  with 
which  to  think  about  virtual  functions,  as  you  do  with  almost  every 
other  feature  in  the  language.  Features  in  a procedural  language 
can  be  understood  on  an  algorithmic  level,  but  virtual  functions  can 
be  understood  only  from  a design  viewpoint. 


15:  Polymorphism  & Virtual  Functions 


661 


Upcasting 

In  Chapter  14 you  saw  how  an  object  can  be  used  as  its  own  type  or 
as  an  object  of  its  base  type.  In  addition,  it  can  be  manipulated 
through  an  addressof  the  base  typaTaking  the  address  of  an 
object  (either  a pointer  or  a reference)  and  treating  it  as  the  address 
of  the  base  type  is  cal  led  upcasting  because  of  the  way  inheritance 
trees  are  drawn  with  the  base  class  at  the  top. 

You  also  saw  a problem  arise,  which  isembodied  in  thefol lowing 
code: 


//:  C15 : Instrument2 . cpp 
//  Inheritance  & upcasting 
#include  <iostream> 
using  namespace  std; 

enum  note  { middleC,  Csharp,  Eflat  };  //  Etc. 

class  Instrument  { 
public : 

void  play (note)  const  { 

cout  <<  " Instrument :: play " <<  endl; 


}; 


//  Wind  objects  are  Instruments 
//  because  they  have  the  same  interface: 
class  Wind  : public  Instrument  { 
public : 

//  Redefine  interface  function: 
void  play (note)  const  { 

cout  <<  "Wind::play"  <<  endl; 


}; 


void  tune (Instruments  i)  { 

/ / ... 

i . play (middleC) ; 

} 

int  main ( ) { 

Wind  flute; 

tune  (flute);  //  Upcasting 
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} III-.- 


Thefunction  tune(  )accepts  (by  reference)  an  Instrument  but  also 
without  complaint  anything  derived  from  Instrument  In  main( ) 
you  can  see  this  happening  as  a Wind  object  is  passed  totune( ) 
with  no  cast  necessary.  This  is  acceptable;  the  i nterface  i n 
Instrumentmust  exist  in  Wind,  because  Wind  is  publicly  inherited 
from  Instrument  Upcasting  from  Windto  Instrumentnay 
"narrow"  that  i nterface,  but  never  I ess  than  the  full  interface  to 
Instrument 

The  same  arguments  are  true  when  dealing  with  pointers;  the  only 
difference  is  that  the  user  must  expl  icitly  take  the  addresses  of 
objects  as  they  are  passed  into  the  function. 


The  problem 

The  problem  with  Instrument2.cppcan  be  seen  by  running  the 
program.  The  output  lslnstrument::playThis  is  cl  early  not  the 
desired  output,  because  you  happen  to  know  that  the  object  is 
actually  a Wind  and  notjustan  InstrumentThecall  should 
produce  Wind::play  For  that  matter,  any  object  of  a class  derived 
from  Instrumenbhould  have  its  version  of  play(  )used,  regardless 
of  the  situation. 

The  behavior  of  Instrument2.cppis  not  surprising,  given  C's 
approach  to  functions.  To  understand  the  issues,  you  need  to  be 
aware  of  the  concept  of  binding. 

Function  call  binding 

Connecting  a function  call  to  a function  body  is  cal  led  binding. 
When  binding  is  performed  before  the  program  is  run  (by  the 
compiler  and  linker),  it'scalled  eariy  binding.  You  may  not  have 
heard  the  term  before  because  it's  never  been  an  option  with 
procedural  languages:  C compilers  have  only  one  kind  of  function 
call,  and  that's  early  binding. 
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The  problem  in  the  program  above  is  caused  by  early  binding 
because  the  compiler  cannot  know  the  correct  function  to  call  when 
it  has  only  an  Instrumentaddress. 

The  solution  iscalled  late  binding,  \Nh\ch  means  the  binding  occurs 
at  runtime,  based  on  the  type  of  the  object.  Late  binding  is  also 
called  dynamic  binding  or  runtime  binding.  When  a language 
i mpl  ements  I ate  bi  nd  i ng,  there  must  be  some  mechani  sm  to 
determinethetypeof  the  object  at  runtime  and  call  the  appropriate 
member  function.  In  the  case  of  a compiled  language,  the  compiler 
still  doesn't  know  the  actual  object  type,  but  it  inserts  code  that 
finds  out  and  cal  Is  the  correct  function  body.  The  late-binding 
mechanism  varies  from  language  to  language,  but  you  can  imagine 
that  some  sort  of  type  information  must  be  installed  in  theobjects. 
You'll  see  how  this  works  later. 


virtual  functions 

To  cause  late  binding  to  occur  for  a particular  function,  C-H- 
requ  ires  that  you  use  the  virtual  keyword  when  declaring  the 
function  in  the  base  cl  ass.  Late  binding  occurs  only  with  virtual 
functions,  and  only  when  you're  using  an  address  of  the  base  class 
where  those  virtual  functions  exist,  although  they  may  also  be 
defined  in  an  earlier  base  cl  ass. 

To  create  a member  function  as  virtual  you  simply  precedethe 
declaration  of  thefunction  with  the  keyword  virtual  Only  the 
declaration  needs  the  virtual  keyword,  not  the  definition.  If  a 
function  isdeclared  asvirtualin  the  base  class,  it  isvirtualin  all  the 
derived  classes.  The  redefinition  of  a virtual  function  in  a derived 
class  is  usually  called  overriding. 

Notice  that  you  are  only  required  to  declare  a function  virtualin 
the  base  class.  All  derived-class  functions  that  match  the  signature 
of  the  base-class  declaration  will  be  called  using  the  virtual 
mechanism.  You  can  use  the  virtual  keyword  in  the  derived-class 
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declarations  (it  does  no  harm  to  do  so),  but  it  is  redundant  and  can 
be  confusing. 

To  get  the  desired  behavior  from  Instrument2.cppsimply  add  the 
virtual  keyword  in  the  base  class  before  play( ) 

//:  C15 : Instruments . cpp 

//  Late  binding  with  the  virtual  keyword 
#include  <iostream> 
using  namespace  std; 

enum  note  { middleC,  Csharp,  Cflat  };  //  Etc. 

class  Instrument  { 
public : 

virtual  void  play (note)  const  { 

cout  <<  "Instrument : :play"  <<  endl; 


}; 


//  Wind  objects  are  Instruments 
//  because  they  have  the  same  interface: 
class  Wind  : public  Instrument  { 
public : 

//  Override  interface  function: 
void  play (note)  const  { 

cout  <<  "Wind::play"  <<  endl; 


}; 


void  tune (Instruments  i)  { 

//  . . . 

i . play (middleC) ; 

} 

int  main ( ) { 

Wind  flute; 

tune  (flute);  //  Upcasting 
} ///:- 

Thisfile  is  identical  to  I nstrument2.cppexcept  for  the  addition  of 
the  virtual  keyword,  and  yet  the  behavior  is  significantly  different: 
Now  the  output  isWind::play 
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Extensibility 

With  play(  )defined  as  virtual  in  the  base  class,  you  can  add  as 
many  new  types  as  you  want  without  changing  thetune( ) 
function.  In  a well-designed  OOP  program,  most  or  all  of  your 
functions  will  follow  the  model  oftune(  )and  communicate  only 
with  the  base-class  interface.  Such  a program  is  eKtensible  because 
you  can  add  new  functionality  by  inheriting  new  data  types  from 
the  common  base  class.  The  functions  that  mani  pul  ate  the  base- 
class  i nterface  wi  1 1 not  need  to  be  changed  at  al  I to  accommodate 
the  new  classes. 

Here'sthe  instrument  example  with  more  virtual  functions  and  a 
number  of  new  classes,  all  of  which  work  correctly  with  the  old, 
unchanged  tune(  )function: 

//:  C15 : Instrument4 . cpp 
//  Extensibility  in  OOP 
#include  <iostream> 
using  namespace  std; 

enum  note  { middleC,  Csharp,  Cflat  };  //  Etc. 

class  Instrument  { 
public : 

virtual  void  play  (note)  const  { 

cout  <<  " Instrument :: play " <<  endl; 

} 

virtual  char*  what ( ) const  { 
return  "Instrument"; 

} 

//  Assume  this  will  modify  the  object: 
virtual  void  adjust  (int)  {} 

}; 


class  Wind  : public  Instrument  { 
public : 

void  play (note)  const  { 

cout  <<  "Wind::play"  <<  endl; 

} 

char*  what ( ) const  { return  "Wind";  } 
void  adjust (int)  {} 

}; 
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class  Percussion  : public  Instrument  { 
public : 

void  play (note)  const  { 

cout  <<  "Percussion :: play"  <<  endl; 

} 

char*  what ( ) const  { return  "Percussion";  } 
void  adjust (int)  {} 

}; 


class  Stringed  : public  Instrument  { 
public : 

void  play (note)  const  { 

cout  <<  "Stringed: :play"  <<  endl; 

} 

char*  what ( ) const  { return  "Stringed";  } 
void  adjust (int)  {} 

}; 


class  Brass  : public  Wind  { 
public : 

void  play (note)  const  { 

cout  <<  "Brass :: play"  <<  endl; 

} 

char*  what  ( ) const  { return  "Brass";  } 

}; 


class  Woodwind  : public  Wind  { 
public : 

void  play (note)  const  { 

cout  <<  "Woodwind :: play " <<  endl; 

} 

char*  what ( ) const  { return  "Woodwind";  } 

}; 


//  Identical  function  from  before: 
void  tune (Instrument&  i)  { 

//  . . . 

i . play (middles ) ; 

} 

//  New  function: 

void  f (Instruments  i)  { i.adjust(l);  } 

//  Upcasting  during  array  initialization: 
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Instrument*  A[]  = { 
new  Wind, 
new  Percussion, 
new  Stringed, 
new  Brass, 


int  main  ( ) { 

Wind  flute; 

Percussion  drum; 

Stringed  violin; 

Brass  flugelhorn; 

Woodwind  recorder; 
tune (flute ) ; 
tune (drum) ; 
tune (violin) ; 
tune (flugelhorn) ; 
tune (recorder) ; 
f (flugelhorn) ; 

} ///:- 

You  can  see  that  another  inheritance  level  has  been  added  beneath 
Wind,  but  the  virtual  mechanism  works  correctly  no  matter  how 
many  levelsthereare.  Theadjust(  )function  is  not  overridden  for 
Brassand  Woodwind  When  this  happens,  the  "closest”  definition 
in  the  inheritance  hierarchy  is  automatically  used  - the  compiler 
guarantees  there'salwayssomedefinition  for  a virtual  function,  so 
you'll  never  end  up  with  a cal  I that  doesn't  bind  to  a function  body. 
(That  would  be  disastrous.) 

The  array  A [ ] contai  ns  pointers  to  the  base  class  I nstrument  so 
upcasting  occurs  during  the  process  of  array  initialization.  This 
array  and  thefuncti on  f( ) will  be  used  in  later  discussions. 

Inthecall  totune( ) upcasting  is  performed  on  each  different  type 
of  object,  yet  the  desired  behavior  alwaystakes  place.  This  can  be 
described  as  "sending  a message  to  an  object  and  letting  the  object 
worry  about  what  to  do  with  it."  The  virtual  function  is  the  lens  to 
use  when  you'retrying  to  analyze  a project:  Where  should  the  base 
classes  occur,  and  how  might  you  want  to  extend  the  program? 
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However,  even  if  you  don't  discover  the  proper  base  class 
i nterfaces  and  virtual  functions  at  the  initial  creation  of  the 
program,  you'll  often  discover  them  later,  even  much  later,  when 
you  set  out  to  extend  or  otherwise  maintain  the  program.  Thisis 
notan  analysis  or  design  error;  it  simply  means  you  didn't  or 
couldn't  know  all  the  information  the  first  time.  Because  of  the  tight 
class  modularization  in  C++,  it  isn't  a large  problem  when  this 
occurs  because  changes  you  make  i n one  part  of  a system  tend  not 
to  propagate  to  other  parts  of  the  system  as  they  do  i n C. 

How  C++  implements  late  binding 

How  can  late  binding  happen?  All  the  work  goes  on  behind  the 
scenes  by  the  compiler,  which  installs  the  necessary  late-binding 
mechanism  when  you  ask  itto  (you  ask  by  creating  virtual 
functions).  Because  programmers  often  benefit  from  understanding 
the  mechanism  of  virtual  functions  in  C-H-,  this  section  will 
elaborate  on  theway  the  compiler  implements  this  mechanism. 

The  keyword  virtual  tel  Is  the  compiler  it  should  not  perform  early 
binding.  Instead,  it  should  automatically  install  all  the  mechanisms 
necessary  to  perform  I ate  binding.  This  means  that  if  you  call 
play(  )for  a Brassobject  through  an  address  for  the  base-class 
I nstrument  you'l  I get  the  proper  functi on. 

To  accomplish  this,  the  typical  compiler^  creates  a single  table 
(called  the  VTA  BLE)  for  each  cl  ass  that  contains  virtual  functions. 
The  compi  I er  places  the  addresses  of  the  vi  rtual  functions  for  that 
particular  class  in  theVTABLE.  In  each  class  with  virtual  functions, 
it  secretly  places  a pointer,  called  the  vpointer  (abbreviated  as 
VPTR),  which  points  to  the  VTA  BLE  for  that  object.  When  you 
make  a virtual  function  call  through  a base-class  pointer  (that  is. 


^Compilers  may  implement  virtual  behavior  any  way  they  want,  butthe  way  it's 
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when  you  makea  polymorphic  call),  the  compiler  quietly  inserts 
code  to  fetch  theVPTR  and  look  up  the  function  address  in  the 
VTABLE,  thus  calling  the  correct  function  and  causing  late  binding 
to  take  place. 

All  of  this-  setting  up  the  VTABLE  for  each  class,  initializing  the 
VPTR,  inserting  the  code  for  the  virtual  function  call  - happens 
automatically,  so  you  don't  have  to  worry  about  it.  With  virtual 
functions,  the  proper  function  gets  cal  led  for  an  object,  even  if  the 
compi  I er  cannot  know  the  specif i c type  of  the  object. 

The  following  sections  go  into  this  process  in  moredetail. 

Storing  type  information 

You  can  see  that  there  is  no  explicit  type  information  stored  in  any 
of  the  classes.  But  the  previous  examples,  and  simplelogic,  tell  you 
that  there  must  be  some  sort  of  type  information  stored  in  the 
objects;  otherwise  the  type  could  not  be  established  at  runtime.  This 
istrue,  but  the  type  information  is  hidden.  To  see  it,  here'san 
exampleto  examinethesizes  of  cl  asses  that  use  virtual  functions 
compared  with  those  that  don't: 

//:  C15 : Sizes . cpp 

//  Object  sizes  with/without  virtuai  functions 
#inciude  <iostream> 
using  namespace  std; 

ciass  NoVirtuai  { 
int  a; 
pubiic : 

void  X ( ) const  { } 

int  i()  const  { return  i;  } 

}; 


ciass  OneVirtuai  { 
int  a; 
pubiic : 

virtuai  void  x()  const  {} 
int  i()  const  { return  i;  } 
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}; 


class  TwoVirtuals 
int  a; 
public : 

virtual  void  x() 
virtual  int  i ( ) 

}; 


{ 


const  { } 

const  { return  1; 


int  main  ( ) { 

cout  <<  "int:  " <<  sizeof(int)  <<  endl; 
cout  <<  "NoVirtual:  " 

<<  sizeof (NoVirtual)  <<  endl; 
cout  <<  "void*  : " <<  sizeof (void* ) <<  endl; 
cout  <<  "OneVirtual:  " 

<<  sizeof (OneVirtual)  <<  endl; 
cout  <<  "TwoVirtuals:  " 

<<  sizeof (TwoVirtuals ) <<  endl; 


} ///:- 


With  no  virtual  fundions,  thesizeof  the  object  is  ©cartly  what 
you'd  expect:  thesizeof  asingle^int  With  a single  virtual  function 
in  OneVirtual  the  size  of  the  object  isthesizeof  NoVirtualplus 
thesizeof  a void  pointer.  It  turns  out  that  the  compiler  inserts  a 
single  pointer  (the  VPTR)  into  the  structure  if  you  have  one  or  more 
virtual  funrtions.  There  is  no  size  difference  between  OneVirtuai 
and  TwoVirtuais  That's  because  theVPTR  points  to  a table  of 
function  addresses.  You  need  only  on  e table  because  all  the  virtual 
function  addresses  are  contained  in  that  single  table. 


This  example  required  at  least  one  data  member.  If  there  had  been 
no  data  members,  the  C++ compiler  would  have  forced  the  objects 
to  be  a nonzero  size  because  each  object  must  have  a distinct 
address.  If  you  imagine  indexing  into  an  array  of  zero-sized  objects, 
you'll  understand.  A "dummy"  member  is  inserted  into  objects  that 
would  otherwise  be  zero-si  zed.  When  the  type  information  is 
i nserted  because  of  the  vi  rtual  keyword , th  i s takes  the  p I ace  of  the 


2 Some  compilers  might  have  size  issues  here  but  it  will  be  rare. 
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"dummy"  member.  Try  commenti  ng  out  the  int  a in  all  the  cl  asses 
in  the  example  above  to  see  this. 

Picturing  virtuai  functions 

To  understand  exactly  what's  going  on  when  you  use  a virtual 
function,  it'shelpful  to  visualize  the  activities  going  on  behind  the 
cu rtai  n . H ere's  a d raw i ng  of  the  array  of  poi  nters  A [ ] i n 

Instrument4.cpp 


VTABLEs: 


The  array  of  I nstrumentpoi  nters  has  no  specific  type  information; 
they  each  point  to  an  object  of  type  Instrument  Wind,  Percussion 
Stringed  and  Brassall  fit  into  this  category  because  they  are 
derived  from  I nstrument(and  thus  have  the  same  i nterface  as 
Instrument  and  can  respond  to  the  same  messages),  so  their 
addresses  can  also  be  placed  into  the  array.  However,  the  compiler 
doesn't  know  that  they  are  anything  more  than  Instrumentobjects, 
so  left  to  its  own  devices  it  would  normally  call  the  base-class 
versions  of  all  the  functions.  But  in  this  case,  all  those  functions 
have  been  declared  with  the  virtual  keyword,  so  something 
different  happens. 
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Each  time  you  create  a cl  ass  that  contains  virtual  functions,  or  you 
derive  from  a cl  ass  that  contai  ns  vi  rtual  fu  net!  ons,  the  compi  I er 
creates  a unique  VTA  BLE  for  that  class,  seen  on  the  right  of  the 
diagram.  In  that  table  it  places  the  addresses  of  all  thefunctions 
that  are  declared  virtual  in  this  class  or  in  the  base  cl  ass.  If  you 
don't  override  a function  that  was  declared  virtual  in  the  base  class, 
the  compi  I er  uses  the  add  ress  of  the  base-cl  ass  versi  on  i n the 
derived  class.  (You  can  seethis in  theadjustentry  in  theBrass 
VTA  BLE.)  Then  it  places  the  VPTR  (discovered  in  Sizes.cpF^  into 
the  class.  There  is  only  oneVPTRfor  each  object  when  using  simple 
inheritance  I ike  this.  The  VPTR  must  beinitialized  to  point  to  the 
starting  address  of  the  appropriate  VTABLE.  (This  happens  in  the 
constructor,  which  you'll  see  later  in  moredetail.) 

Once  the  VPTR  is  initialized  to  the  proper  VTABLE,  the  object  in 
effect  "knows"  what  type  it  is.  But  this  self-knowledge  is  worthless 
unless  it  is  used  at  the  point  a virtual  function  is  called. 

When  you  call  a virtual  function  through  a base  class  address  (the 
situation  when  the  compiler  doesn't  have  all  the  information 
necessary  to  perform  early  binding),  something  special  happens. 
Instead  of  performing  atypical  function  call,  which  issimply  an 
assembi  y-l  anguage  C A L L to  a parti  cu  I ar  ad  d ress,  the  compi  I er 
generates  different  code  to  perform  the  function  call.  Here's  what  a 
call  to  adjust(  )for  a Brassobject  looks  like,  if  madethrough  an 
Instrumentpointer  (An  I nstrumentreference  produces  the  same 
result): 


nstrument 

pointer 


Brass  VTABLE: 


Brass  object  ^ 

[0] 

: 

•^[2] 

SiBrass: : play 

vptr  •" 

SiBrass: : what 

&Wind: : adj  ust 

The  compiler  begins  with  the  Instrumentpointer,  which  points  to 
the  starti  ng  address  of  the  object.  A 1 1 1 nstrumentobjects  or  objects 
derived  from  I nstrumenthave  their  VPTR  in  the  same  place  (often 
at  the  beginning  of  the  object),  so  the  compiler  can  pick  the  VPTR 
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outof  the  object.  The  VPTR  points  to  the  starting  address  of  the 
VTABLE.  All  theVTABLE  function  addresses  are  laid  out  in  the 
same  order,  regardlessof  the  specific  type  of  the  object.  play(  )is 
first,  what(  )is  second,  and  adjust(  )isthird.  The  compiler  knows 
that  regard  I ess  of  the  specific  object  type,  the  adjust(  )function  is  at 
the  location  VPTR+2.  Thus,  instead  of  saying,  "Call  thefunction  at 
the  absolute  location  lnstrument::adju^(early  binding;  the  wrong 
action),  it  generates  code  that  says,  in  effect,  "Call  thefunction  at 
VPTR+2."  Because  the  fetching  of  theVPTR  and  the  determination 
of  the  actual  function  ad  dress  occur  at  runtime,  you  get  the  desired 
I ate  bi  nd  i ng.  Y ou  send  a message  to  the  object,  and  the  object 
figures  out  what  to  do  with  it. 

Under  the  hood 

It  can  be  helpful  to  seethe  assembly-language  code  generated  by  a 
virtual  function  call,  so  you  can  see  that  late-binding  is  indeed 
taking  place.  Here's  the  output  from  one  compiler  for  the  cal  I 

I i . adjust  ( 1 ) ; 

insidethefunction  f(lnstrument&  i) 


push 

1 

push 

si 

mov 

bx,  word 

ptr  [ s 

call 

word  ptr 

[bx+4] 

add 

sp,  4 

The  argu  ments  of  a C-H- function  call,  likeaC  function  call,  are 
pushed  on  the  stack  from  ri  ght  to  I eft  (this  order  i s requ  i red  to 
support  C's  variable  argument  I ists),  so  the  argument  1 is  pushed 
on  the  stack  first.  At  this  point  in  thefunction,  the  register  si  (part 
of  theintel  X86  processor  architecture)  containstheaddressof  i. 
This  is  also  pushed  on  the  stack  because  it  isthestarting  address  of 
the  object  of  i nterest.  Remember  that  the  start!  ng  add  ress 
corresponds  to  the  value  of  this  and  thisisquietly  pushed  on  the 
stack  as  an  argument  before  every  member  function  cal  1,  so  the 
member  function  knows  which  particular  object  it  is  working  on. 


674 


Thinking  in  C-I--I- 


www.BruceEckel.com 


So  you'll  always  see  one  more  than  the  number  of  arguments 
pushed  on  the  stack  before  a member  function  call  (except  for  static 
member  functions,  which  have  no  this). 

Now  the  actual  virtual  function  call  must  be  performed.  First,  the 
VPTR  must  be  produced,  sotheVTABLE  can  befound.  For  this 
compiler  the  VPTR  is  inserted  at  the  beginning  of  the  object,  so  the 
contents  of  th i s correspond  to  the  V PTR.  The  I i ne 

mov  bx,  word  ptr  [si] 

fetches  the  word  that  si  (that  is,  this)  points  to,  which  istheVPTR. 

It  places  the  VPTR  into  the  register  bx. 

The  VPTR  contained  in  bx  points  to  the  starting  address  of  the 
VTABLE,  but  the  function  pointer  to  call  isn't  at  location  zero  of  the 
VTABLE,  but  instead  at  location  two  (because  it's  the  third  function 
in  the  list).  For  this  memory  model  each  function  pointer  is  two 
bytes  I ong,  so  the  compi  I er  add  s fou  r to  the  V PTR  to  cal  cu  I ate 
wherethe  address  of  the  proper  function  is.  Note  that  this  is  a 
constant  value,  established  at  compile  time,  so  the  only  thing  that 
matters  is  that  the  function  pointer  at  location  number  two  is  the 
onefor  adjust( ) Fortunately,  thecompiler  takes  care  of  all  the 
bookkeeping  for  you  and  ensures  that  all  the  function  pointers  in 
all  theVTABLEsof  a particular  class  hierarchy  occur  in  the  same 
order,  regardlessof  the  order  that  you  may  override  them  in 
derived  classes. 

Once  the  ad  dress  of  the  proper  function  pointer  in  the  VTABLE  is 
calculated,  that  function  is  cal  led.  So  the  address  is  fetched  and 
cal  I ed  al  I at  once  i n the  statement 

call  word  ptr  [bx+4] 

Fi  nal  ly,  the  stack  poi  nter  is  moved  back  up  to  clean  off  the 
argumentsthat  were  pushed  before  the  call.  In  C and  C++ 
assembly  code  you'll  often  see  the  caller  clean  off  the  arguments 
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but  this  may  vary  depend i ng  on  processors  and  compi  I er 
implementations. 

I nstalling  the  vpointer 

Because  the  VPTR  determines  the  virtual  function  behavior  of  the 
object,  you  can  see  how  it's  critical  that  the  VPTR  always  be 
pointing  to  the  proper  VTA BLE.  You  don't  ever  want  to  beableto 
make  a cal  I to  a virtual  function  before  the  VPTR  is  properly 
initialized.  Of  course,  the  place  where  initialization  can  be 
guaranteed  is  i n the  constructor,  but  none  of  the  I nstrument 
examples  has  a constructor. 

This  is  where  creation  of  the  default  constructor  is  essential . I n the 
I nstrumentexamples,  the  compiler  creates  a default  constructor 
that  does  nothing  except  initializetheVPTR.  This  constructor,  of 
course,  is  automatically  called  for  all  Instrumentobjects  before  you 
can  do  anything  with  them,  so  you  know  that  it's  always  safe  to  call 
virtual  functions. 

Theimplicationsof  the  automatic  initialization  oftheVPTR  inside 
the  constructor  are  discussed  in  a later  section. 

Objects  are  different 

It's  important  to  realize  that  upcasting  deals  only  with  addresses.  If 
the  compiler  has  an  object,  it  knows  the  exact  type  and  therefore  (in 
C ++)  will  not  use  I ate  bi  nd  i ng  for  any  fu  ncti  on  cal  I s - or  at  I east,  the 
compiler  doesn't  need  to  use  late  binding.  For  efficiency's  sake, 
most  compilers  will  perform  early  binding  when  they  are  making  a 
call  to  a virtual  function  for  an  object  because  they  know  the  exact 
type.  Here's  an  example: 

// : C15 : Early . cpp 

//  Early  binding  & virtual  functions 
#include  <iostream> 

#include  <string> 
using  namespace  std; 
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!!  !f  . 


class  Pet  { 
public : 

virtual  string  speak  ()  const  { return 

}; 


class  Dog  : public  Pet  { 
public : 

string  speak ()  const  { return  "Bark!";  } 

}; 


int  main  ( ) { 

Dog  ralph; 

Pet*  pi  = &ralph; 

Pet&  p2  = ralph; 

Pet  p3; 

//  Late  binding  for  both: 

cout  <<  "pl->speak()  = " <<  pl->speak()  <<endl; 

cout  <<  "p2. speak  0 = " <<  p2. speak  ()  <<  endl; 

//  Early  binding  (probably) : 

cout  <<  "p3. speak  0 = " <<  p3. speak  ()  <<  endl; 

} ///:- 

In  pl->speak(  )and  p2.speak( ) addresses  are  used,  which  means 
the  information  is  incomplete:  pland  P2  can  represent  the  address 
of  a Pet  or  something  derived  from  Pet  so  the  virtual  mechanism 
must  be  used.  When  calling  p3.speak(  )there'sno  ambiguity.  The 
compiler  knows  the  exact  type  and  that  it's  an  object,  so  it  can't 
possibly  bean  object  derived  from  Pet-  it's  exactly  a Pet  Thus, 
early  binding  is  probably  used.  However,  if  the  compiler  doesn't 
want  to  work  so  hard,  it  can  still  use  late  binding  and  the  same 
behavior  will  occur. 


Why  virtual  functions? 

At  this  point  you  may  have  a question:  "If  this  technique  is  so 
important,  and  if  it  makes  the 'right'  function  call  all  the  time,  why 
is  it  an  option?  Why  do  I even  need  to  know  about  it?" 
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Thi  s i s a good  questi  on,  and  the  answer  i s part  of  the  fu ndamental 
philosophy  of  C++:  "Because  it's  not  quite  as  efficient."  You  can  see 
from  the  previous  assembly-language  output  that  i nstead  of  one 
simpleCALL  to  an  absolute  address,  there  are  two-  more 
sophisticated  - assembly  instructions  required  to  set  up  the  virtual 
function  call.  This  requires  both  code  space  and  execution  time. 

Some  object-oriented  languages  have  taken  the  approach  that  late 
binding  is  so  intrinsic  to  object-oriented  programming  that  it 
should  always  take  place,  that  it  should  not  bean  option,  and  the 
user  shouldn't  have  to  know  about  it.  This  is  a design  decision 
when  creating  a language,  and  that  particular  path  is  appropriate 
for  many  I anguages.3  However,  C-H- comes  from  the  C heritage, 
where  efficiency  is  critical.  After  all,  C was  created  to  replace 
assembly  languagefor  the  implementation  of  an  operating  system 
(thereby  rendering  that  operating  system  - Unix  - far  more 
portable  than  its  predecessors).  One  of  the  main  reasons  for  the 
invention  of  C-H- was  to  makeC  programmers  more  efficient.^  And 
the  first  questi  on  asked  when  C programmers  encounter  C-H- is, 
"What  kind  of  size  and  speed  impact  will  I get?"  If  the  answer 
were,  "Everything'sgreatexceptfor  function  callswhen  you'll 
always  havea  little  extra  overhead,"  many  peoplewould  stick  with 
C rather  than  make  the  change  to  C-H-.  In  addition,  inline  functions 
would  not  be  possible,  because  virtual  functions  must  have  an 
address  to  put  into  the  VTABLE.  So  the  virtual  function  isan 
option,  and  the  language  defaults  to  nonvirtual,  which  isthefastest 
configuration.  Stroustrup  stated  that  his  guideline  was,  "If  you 
don't  use  it,  you  don't  pay  for  it." 

Thus,  the  virtual  keyword  is  provided  for  efficiency  tuning.  When 
designing  your  classes,  however,  you  shouldn't  beworrying  about 
efficiency  tuning.  If  you're  going  to  use  polymorphism,  use  virtual 


3 Smalltalk,  Java,  and  Python,  for  instance,  use  this  approach  with  great  success. 
^AtBell  Labs,  whereC-H-wasinvented,  there  area /of  of  C programmers.  Making 
them  ail  more  efficient,  even  just  a bit,  saves  the  company  many  millions. 
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functions  everywhere.  You  only  need  to  look  for  functions  that  can 
bemadenon-virtual  when  searching  for  ways  to  speed  up  your 
code  (and  there  are  usually  much  bigger  gal  ns  to  be  had  in  other 
areas -a  good  profiler  will  do  a better  job  of  finding  bottlenecks 
than  you  will  by  making  guesses). 

Anecdotal  evidence  suggests  that  the  size  and  speed  impacts  of 
going  to  C++ are  within  10  percent  of  the  size  and  speed  of  C,  and 
often  much  closer  to  the  same.  The  reason  you  might  get  better  size 
and  speed  efficiency  is  because  you  may  design  a C++program  in  a 
smaller,  faster  way  than  you  would  using  C. 


Abstract  base  classes  and  pure 
virtual  functions 

Often  i n a design,  you  want  the  base  class  to  present  only  an 
interface  for  its  derived  classes.  That  is,  you  don't  want  anyone  to 
actual  ly  create  an  object  of  the  base  class,  only  to  upcast  to  it  so  that 
its  interface  can  be  used.  This  is  accomplished  by  making  that  class 
abstract,  which  happens  if  you  give  it  at  least  one  pure  virtual 
function. \o\j  can  recognize  a pure  virtual  function  becauseit  uses 
the  virtual  keyword  and  isfollowed  by  = 0.  If  anyone  tries  to  make 
an  object  of  an  abstract  class,  the  compi  ler  prevents  them.  This  is  a 
tool  that  allows  you  toenforcea  particular  design. 

When  an  abstract  class  is  inherited,  all  pure  virtual  functions  must 
be  implemented,  or  the  inherited  class  becomes  abstract  as  well. 
Creating  a pure  virtual  function  allows  you  to  put  a member 
function  in  an  interface  without  being  forced  to  providea  possibly 
meaningless  body  of  codefor  that  member  function.  At  the  same 
time,  a pure  virtual  function  forces  inherited  classes  to  providea 
definition  for  it. 

I n al  I of  the  i nstru  ment  exampi  es,  the  fu  ncti  ons  i n the  base  cl  ass 
I nstrumentwere  always  "dummy"  functions.  If  these  functions  are 
ever  called,  something  is  wrong.  That's  becausethe  intent  of 
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I nstrument  s to  create  a common  i nterface  for  al  I of  the  cl  asses 
derived  from  it. 


The  only  reason  to  establish  the  common  I nterface  is  so  it  can  be 
expressed  differently  for  each  different  subtype.  It  creates  a basic 
form  that  determines  what's  in  common  with  all  of  the  derived 
classes-  nothing  else.  So  Instrumentisan  appropriate  candidate  to 
bean  abstract  class.  You  create  an  abstract  class  when  you  only 
want  to  manipulatea  set  of  cl  asses  through  a common  interface, 
but  the  common  interface  doesn't  need  to  have  an  implementation 
(or  at  least,  a full  implementation). 

If  you  have  a concept  I i ke  I nstrumentthat  works  as  an  abstract 
class,  objects  of  that  class  almost  always  have  no  meaning.  That  is, 

I nstrument  s meant  to  express  only  the  I nterface,  and  not  a 
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particular  implementation,  so  creating  an  object  that  isonly  an 
Instrumentmakes  no  sense,  and  you'll  probably  want  to  prevent 
the  user  from  doing  it.  This  can  be  accompli  shed  by  making  all  the 
virtual  functions  in  Instrumentprint  error  messages,  but  that 
del  ays  the  appearance  of  the  error  information  until  runtime  and  it 
requires  reliable  exhaustive  testing  on  thepart  of  theuser.  It  is 
much  better  to  catch  the  problem  at  compile  time. 

Here  is  the  syntax  used  fora  pure  virtual  declaration: 

virtual  void  f()  =0; 

By  doi  ng  this,  you  tel  I the  comp i I er  to  reserve  a si ot  for  a functi on 
in  theVTABLE,  but  not  to  put  an  address  in  that  particular  slot. 
Even  if  only  one  function  in  a class  is  declared  as  pure  virtual,  the 
VTABLE  is  incomplete. 

If  theVTABLE  for  a class  is  incomplete,  what  isthe  compiler 
supposed  to  do  when  someone  tries  to  make  an  object  of  that  class? 
It  cannot  safely  create  an  object  of  an  abstract  class,  so  you  get  an 
error  message  from  the  compi  I er.  Thus,  the  compi  I er  guarantees  the 
purity  of  the  abstract  class.  By  maki  ng  a class  abstract,  you  ensure 
that  the  client  programmer  cannot  misuseit. 

Here's  I nstrument4.cppmodified  to  use  pure  virtual  functions. 
Because  the  class  has  nothing  but  pure  virtual  functions,  we  cal  I ita 
pure  abstract  class-. 

//:  C15 : Instruments . cpp 
//  Pure  abstract  base  classes 
#include  <iostream> 
using  namespace  std; 

enum  note  { middleC,  Csharp,  Cflat  };  //  Etc. 

class  Instrument  { 
public : 

//  Pure  virtual  functions: 
virtual  void  play (note)  const  = 0; 
virtual  char*  what ( ) const  = 0; 

//  Assume  this  will  modify  the  object: 
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virtual  void  adjust (int)  = 0; 

}; 

//  Rest  of  the  file  is  the  same  . . . 

class  Wind  : public  Instrument  { 
public : 

void  play (note)  const  { 

cout  <<  "Wind::play"  <<  endl; 

} 

char*  what ( ) const  { return  "Wind";  } 
void  adjust (int)  {} 

}; 

class  Percussion  : public  Instrument  { 
public : 

void  play (note)  const  { 

cout  <<  "Percussion :: play"  <<  endl; 

} 

char*  what ( ) const  { return  "Percussion";  } 
void  adjust (int)  {} 

}; 

class  Stringed  : public  Instrument  { 
public : 

void  play (note)  const  { 

cout  <<  "Stringed: :play"  <<  endl; 

} 

char*  what ( ) const  { return  "Stringed";  } 
void  adjust (int)  {} 

}; 

class  Brass  : public  Wind  { 
public : 

void  play (note)  const  { 

cout  <<  "Brass :: play"  <<  endl; 

} 

char*  what  ( ) const  { return  "Brass";  } 

}; 

class  Woodwind  : public  Wind  { 
public : 

void  play (note)  const  { 

cout  <<  "Woodwind :: play " <<  endl; 

} 

char*  what ( ) const  { return  "Woodwind";  } 
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}; 


//  Identical  function  from  before: 
void  tune (Instruments  i)  { 

//  . . . 

i . play (middleC) ; 

} 

//  New  function: 

void  f (Instruments  i)  { i. adjust (I);  } 

int  main  ( ) { 

Wind  flute; 

Percussion  drum; 

Stringed  violin; 

Brass  flugelhorn; 

Woodwind  recorder; 
tune  (flute ) ; 
tune (drum) ; 
tune (violin) ; 
tune (flugelhorn) ; 
tune (recorder) ; 
f (flugelhorn) ; 

} ///:- 

Pure  virtual  functions  are  helpful  because  they  make  explicit  the 
abstractnessof  a classand  tell  both  the  user  and  the  compiler  how 
it  was  intended  to  be  used. 

Note  that  pure  virtual  functions  prevent  an  abstract  cl  ass  from 
being  passed  into  a function  by  value.  Thus,  it  is  also  a way  to 
prevent  object  slicing  (which  will  be  described  shortly).  By  making  a 
class  abstract,  you  can  ensure  that  a pointer  or  reference  is  always 
used  during  upcasting  to  that  class. 

Just  because  one  pure  virtual  function  prevents  the  VTABLE  from 
being  completed  doesn't  mean  that  you  don't  want  function  bodies 
for  some  of  the  others.  Often  you  will  want  to  cal  I a base-class 
version  of  a function,  even  if  it  is  virtual.  It's  always  a good  idea  to 
put  common  code  as  close  as  possible  to  the  root  of  your  hierarchy. 
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N ot  only  does  this  save  code  space,  it  al  lows  easy  propagation  of 
changes. 


Pure  virtual  definitions 

It's  possibleto  provide  a definition  for  a pure  virtual  function  in  the 
base  cl  ass.  You're  still  tel  ling  the  compiler  not  to  allow  objects  of 
that  abstract  base  class,  and  the  pure  virtual  functions  must  still  be 
defined  in  derived  classes  in  order  to  create  objects.  However,  there 
may  be  a common  piece  of  code  that  you  want  some  or  al  I of  the 
derived  cl  ass  definitions  to  call  rather  than  duplicating  that  code  in 
every  function. 

Here's  what  a pure  virtual  definition  looks  like: 

// : C15 : PureVirtualDef initions . cpp 
//  Pure  virtual  base  definitions 
#include  <iostream> 
using  namespace  std; 


class  Pet  { 
public : 

virtual  void  speak  ()  const  = 0; 
virtual  void  eat()  const  = 0; 

//  Inline  pure  virtual  definitions  illegal: 
//!  virtual  void  sleep  ()  const  = 0 {} 


//  OK,  not  defined  inline 
void  Pet::eat()  const  { 

cout  <<  "Pet::eatO"  <<  endl; 

} 


void  Pet :: speak  0 const  { 

cout  <<  "Pet :: speak  0 " <<  endl; 

} 

class  Dog  : public  Pet  { 
public : 

//  Use  the  common  Pet  code: 

void  speak  0 const  { Pet :: speak  () ; } 

void  eat()  const  { Pet::eat();  } 
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}; 


int  main  ( ) { 

Dog  simba;  //  Richard's  dog 
simba . speak  ( ) ; 
simba . eat  ( ) ; 

} ///:- 

The  slot  in  the  Pet  VTA  BLE  is  still  ennpty,  but  there  happens  to  be  a 
function  by  that  name  that  you  can  call  in  the  derived  class. 

The  other  benefit  to  thi  s featu re  i s that  it  al  I ows  you  to  change  from 
an  ordi nary  vi rtual  to  a pure  vi rtual  without  disturb! ng  the existi ng 
code.  (This  is  a way  for  you  to  locate  cl  asses  that  don't  overridethat 
virtual  function.) 


I nheritance  and  the  VTABLE 

You  can  imagine  what  happens  when  you  perform  inheritance  and 
overri  de  some  of  the  vi  rtual  fu  ncti  ons.  The  compi  I er  creates  a new 
VTABLE  for  your  new  class,  and  it  inserts  your  new  function 
addresses  using  the  base-class  function  addresses  for  any  virtual 
functions  you  don't  override.  Oneway  or  another,  for  every  object 
that  can  be  created  (that  is,  its  class  has  no  pure  virtuals)  there's 
always  a full  set  of  function  addresses  in  the  VTABLE,  so  you'll 
never  be  able  to  make  a call  to  an  address  that  isn't  there  (which 
would  be  disastrous). 

But  what  happens  when  you  inherit  and  add  new  virtual  functions 
in  thederived  class?  Here's  a simple  example: 

//:  C15 : AddingVirtuals . cpp 
//  Adding  virtuals  in  derivation 
#include  <iostream> 

#include  <string> 
using  namespace  std; 

class  Pet  { 
string  pname; 
public : 
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Pet (const  Strings  petName)  : pname (petName ) {} 

virtual  string  name()  const  { return  pname;  } 
virtual  string  speak ()  const  { return  } 


class  Dog  : public  Pet  { 
string  name; 
public : 

Dog (const  strings  petName)  : Pet (petName)  {} 
//  New  virtual  function  in  the  Dog  class: 
virtual  string  sit()  const  { 
return  Pet :: name ()  + " sits"; 

} 

string  speak  ()  const  { //  Override 

return  Pet :: name ()  + " says  'Bark!'"; 


}; 


int  main  ( ) { 

Pet*  p[]  = {new  Pet  ( "generic"  ),  new  DogC'bob")}; 
cout  <<  "p [ 0 ] ->speak ( ) = " 

<<  p [ 0 ] ->speak  ( ) <<  endl; 

cout  <<  "p [ 1 ] ->speak ( ) = " 

<<  p [ 1 ] ->speak ( ) <<  endl; 

//!  cout  <<  "p[l]->sit()  = " 

//!  <<  p[l]->sit()  <<  endl;  //  Illegal 

} ///:- 

The  class  Petcontains  a two  virtual  functions:  speak(  )and  name( ) 
Dog  adds  a third  virtual  function  called  sit( ) as  well  as  overriding 
the  meaning  of  speak( ) A diagram  will  helpyou  visualize  what's 
happening.  Here  are  the  VTA  BLEs  created  by  the  compiler  for  Pet 
and  Dog: 
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Notice  that  the  compiler  maps  the  location  of  thespeak(  )address 
i nto  exacti y the  same  spot  i n the  D og  VTA  BL  E as  i t i s i n the  Pet 
VTABLE.  Similarly,  if  a class  Pug  is  inherited  from  Dog,  its  version 
of  sit(  )would  be  placed  in  its  VTABLE  in  exactly  the  same  spot  as 
it  is  in  Dog.  This  is  because  (as  you  saw  with  the  assembly- 
language  example)  the  compiler  generates  code  that  uses  a simple 
numerical  offset  into  the  VTABLE  to  select  the  virtual  function. 
Regard  I ess  of  the  specif  i c su  bty  pe  the  object  bel  ongs  to,  i ts  VTA  BL  E 
is  laid  out  the  same  way,  so  cal  Is  to  the  virtual  functions  will 
always  be  made  the  same  way. 

In  this  case,  however,  the  compiler  is  working  only  with  a pointer 
to  a base-class  object.  The  base  class  has  only  thespeak(  )and 
name(  )f  unctions,  so  those  is  the  only  functions  the  compi  ler  will 
allow  you  to  call.  How  could  it  possibly  know  that  you  are  working 
with  a Dog  object,  if  it  has  only  a pointer  to  a base-class  object? 

That  pointer  might  point  to  some  other  type,  which  doesn't  have  a 
sit(  )function.  It  may  or  may  not  have  some  other  function  address 
at  that  point  in  the  VTABLE,  but  in  either  case,  making  a virtual  call 
to  that  VTABLE  address  is  not  what  you  want  to  do.  So  the 
compiler  is  doing  its  job  by  protecting  you  from  making  virtual 
cal  Is  to  functions  that  exist  only  in  derived  classes. 

There  are  some  less-common  cases  in  which  you  may  know  that  the 
pointer  actually  points  to  an  object  of  a specific  subclass.  If  you 
want  to  call  a function  that  only  exists  in  that  subclass,  then  you 
must  cast  the  pointer.  You  can  remove  the  error  message  produced 
by  the  previous  program  likethis: 

( (Dog*) p [ 1] ) ->sit ( ) 

H ere,  you  happen  to  know  that  p[l]  poi  nts  to  a D og  object,  but  i n 
general  you  don't  know  that.  If  your  problem  is  set  up  so  that  you 
must  know  the  exact  types  of  al  I objects,  you  should  rethink  it, 
because  you're  probably  not  using  virtual  functions  properly. 
However,  there  are  some  situations  in  which  the  design  works  best 
(or  you  have  no  choi  ce)  if  you  know  the  exact  type  of  al  I objects 
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kept  in  a generic  container.  This  is  the  probienn  of  run-time  type 
identification  (RTTI). 

RTTI  is  aii  about  casting  base-ciass  pointers  down  to  derived-dass 
pointers  ("up"  and  "down"  arereiativeto  atypicai  ci ass  diagram, 
with  the  base  dass  at  the  top).  Casting  up  happens  automaticaiiy, 
with  no  coercion,  because  it's  compietdy  safe.  Casting  down  is 
unsafe  because  there's  no  complied  me  information  about  the 
actual  types,  so  you  must  know  exactly  what  type  the  object  is.  If 
you  cast  it  into  the  wrong  type,  you'll  be  in  trouble. 

RTTI  is  described  later  in  this  chapter,  and  Volume  2 of  this  book 
has  a chapter  devoted  to  the  subject. 

Object  slicing 

There  is  a distinct  difference  between  passi  ng  the  addresses  of 
objects  and  passing  objects  by  value  when  using  polymorphism. 

All  the  examples  you've  seen  here,  and  virtually  all  theexamples 
you  should  see,  pass  addresses  and  not  values.  This  is  because 
addresses  all  have  the  same  si  ze^,  so  passing  the  address  of  an 
object  of  a derived  type  (which  is  usually  a bigger  object)  isthe 
same  as  passi  ng  the  add  ress  of  an  object  of  the  base  type  (w  hi  ch  i s 
usually  a smaller  object).  As  explained  before,  this  is  the  goal  when 
using  polymorphism  - code  that  manipulates  a base  type  can 
transparently  mani  pul  ate  derived-type  objects  as  wel  I . 

If  you  upcast  to  an  object  i nstead  of  a poi  nter  or  reference, 
something  will  happen  that  may  surprise  you:  the  object  is  "sliced" 
until  all  that  remains  isthesubobject  that  correspondsto  the 
destination  typeof  your  cast.  In  the  foil  owing  example  you  can  see 
what  happens  when  an  object  is  sliced: 

I //:  C15 : Ob jectSlicing . cpp 


^Actually,  not  all  pointers  are  the  same  size  on  all  machines.  In  the  context  of  this 
discussion,  however,  they  can  be  considered  to  be  the  same. 
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#include  <iostream> 

#include  <string> 
using  namespace  std; 

class  Pet  { 
string  pname; 
public : 

Pet  (const  Strings  name)  : pname (name)  {} 
virtual  string  name()  const  { return  pname;  } 
virtual  string  description ( ) const  { 
return  "This  is  " + pname; 


}; 


class  Dog  : public  Pet  { 
string  f avoriteActivity; 
public : 

Dog (const  strings  name,  const  strings  activity) 
: Pet (name) , f avoriteActivity (activity)  {} 
string  description ( ) const  { 

return  Pet :: name ()  + " likes  to  " + 
f avoriteActivity; 


}; 


void  describe (Pet  p)  { //  Slices  the  object 
cout  <<  p . description ( ) <<  endl; 

} 


int  main  ( ) { 

Pet  p( "Alfred"); 

Dog  dC'Fluffy",  "sleep"); 
describe (p) ; 
describe (d) ; 

} ///:- 

The  fundi  on  describe(  )is  passe(d  an  objed  of  type  Pet  by  value.  It 
then  cal  Is  the  virtual  fundion  description(  )for  thePetobjed.  In 
main( ) you  might  exped  the  fi  rst  cal  I to  produce  "This  is  Alfred," 
and  the  second  to  produce  "Fluffy  likes  to  sleep."  In  fad,  both  calls 
usethe  base-class  version  of  description ( ) 
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Two  things  are  happening  in  this  program.  First,  because 
descri  be(  )accepts  a Pet  object  (rather  than  a poi  nter  or  reference), 
any  cai  is  to  describee  )wiii  cause  an  object  the  size  of  Petto  be 
pushed  on  the  stack  and  deaned  up  afterthecaii.  This  means  that  if 
an  object  of  a ci ass  inherited  from  Petis  passed  to  descri be(  )the 
compi  ier  accepts  it,  but  it  copies  oniy  the  Pet  portion  of  the  object, 
it  s//ces  the  derived  portion  off  of  the  object,  iikethis: 


Before  Slice 


After  Slice 


Dog  vptr 

> 

Pet  vptr 

pname 

^ . 

pname 

favoriteActivity 

Now  you  may  wonder  about  the  virtuai  function  caii. 
Dog::description(  )nakesuseof  portions  of  both  Pet(which  stiii 
exists)  and  Dog,  which  no  ionger  exists  because  it  was  si  iced  off!  So 
what  happens  when  the  virtuai  function  iscaiied? 

You're  saved  from  disaster  because  the  object  is  being  passed  by 
vaiue.  Because  of  this,  the  compi  ier  knows  the  precise  type  of  the 
object  because  the  derived  object  has  been  forced  to  become  a base 
object.  When  passing  by  vaiue,  the  copy-constructor  for  a Pet  object 
isused,  which  initiaiizestheVPTRto thePetVTABLE  and  copies 
oniy  the  Pet  parts  of  the  object.  There's  no  expiicit  copy-constructor 
here,  so  the  compi  ier  synthesizes  one.  Under  aii  interpretations,  the 
object  truiy  becomes  a Pet  during  siicing. 

Objectsiicing  actuaiiy  removes  part  of  the  existing  object  as  it 
copies  it  into  the  new  object,  rather  than  simpiy  changing  the 
meaning  of  an  address  as  when  using  a pointer  or  reference. 
Because  of  this,  upcasting  into  an  object  is  not  done  often;  in  fact, 
it's  usuaiiy  something  to  watch  out  for  and  prevent.  Note  that,  in 
thisexampie,  if  descri pti on ( )were  made  into  a pure  virtuai 
function  in  the  based  ass  (which  isnotunreasonabie,  sinceit 
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doesn't  real  ly  do  anythi  ng  i n the  base  class),  then  the  compi  I er 
would  prevent  object  slicing  becausethat  wouldn't  allow  you  to 
"create"  an  object  of  the  base  type  (which  is  what  happens  when 
you  upcast  by  value).  This  could  bethemost  innportant  valueof 
pure  virtual  functions:  to  prevent  object  slicing  by  generating  a 
compi  le-ti  me  error  message  if  someone  tries  to  do  it. 


Overloading  & overriding 

In  Chapter  14,  you  saw  that  redefining  an  overloaded  function  in 
the  base  class  hides  al  I of  the  other  base-class  versions  of  that 
function.  When  virtual  functions  are  involved  the  behavior  is  a 
little  different.  Consider  a modified  version  of  the 
NameHiding.cppexamplefrom  Chapter  14: 

//:  C15 : NameHiding2 . cpp 

//  Virtual  functions  restrict  overloading 
#include  <iostream> 

#include  <string> 
using  namespace  std; 

class  Base  { 
public : 

virtual  int  f()  const  { 
cout  <<  "Base : : f ( ) \n" ; 
return  1; 


virtual  void  f (string)  const  {} 
virtual  void  g()  const  {} 


class  Derivedl  : public  Base  { 
public : 

void  g ( ) const  { } 

}; 


class  Derived2  : public  Base  { 
public : 

//  Overriding  a virtual  function: 
int  f ( ) const  { 

cout  <<  "Derived2 : : f ( ) \n" ; 
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return  2; 


} 


}; 


class  DerivedS  : public  Base  { 
public : 

//  Cannot  change  return  type: 

//!  void  f()  const { cout  <<  "DerivedS : : f ( ) \n"  ; } 


class  Derived4  : public  Base  { 
public : 

//  Change  argument  list: 
int  f ( int ) const  { 

cout  <<  "Derived4 : : f ( ) \n" ; 
return  4; 


}; 


int  main  ( ) { 

string  s ("hello"); 

Derivedl  dl ; 
int  X = dl . f ( ) ; 
dl . f (s)  ; 

DerivedC  d2 ; 

X = d2 . f ( ) ; 

//!  d2.f(s);  //  string  version  hidden 

Derived4  d4 ; 

X = d4 . f (1)  ; 

//!  x=d4.f();  //  f()  version  hidden 

//!  d4.f(s);  //  string  version  hidden 

Base&  br  = d4 ; //  Upcast 
//!  br.f(l);  //  Derived  version  unavailable 
br.fO;  //  Base  version  available 
br.f(s);  //  Base  version  abailable 
} ///:- 

The  f i rst  thi  ng  to  noti  ce  i s that  i n D eri  ved3  the  compi  I er  w i 1 1 not 
allow  you  to  change  the  return  type  of  an  overridden  function  (it 
will  allow  it  iffOi  snot  virtual).  This  is  an  important  restriction 
because  the  compiler  must  guarantee  that  you  can  polymorphically 
call  the  function  through  the  base  cl  ass,  and  if  the  base  cl  ass  is 
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expecting  an  intto  be  returned  from  f(),  then  the  derived -cl  ass 
version  off(  )must  keep  that  contract  or  else  things  will  break. 


Theruleshown  in  Chapter  14  still  works:  if  you  override  one  of  the 
overloaded  member  functions  in  the  base  class,  the  other 
overloaded  versions  become  hidden  in  thederived  class.  In  main( ) 
the  codethattestsDerived4showsthat  this  happens  even  if  the 
new  version  of  f( ) isn't  actually  overriding  an  existing  virtual 
function  interface-  both  of  the  base-class  versions  of  f(  )are  hidden 
byf(int>  However,  if  you  upcast  d 4 to  Base  then  only  the  base- 
class  versions  are  aval  I able  (because  that's  what  the  base-class 
contract  promises)  and  the  derived-class  version  is  not  available 
(because  it  isn't  specified  in  the  base  class). 

Variant  return  type 

The  DerivedScI  ass  above  suggests  that  you  cannot  modify  the 
return  typeof  a virtual  function  during  overriding.  This  is 
generally  true,  but  there  is  a special  casein  which  you  can  slightly 
modify  the  return  type.  If  you're  returning  a pointer  or  a reference 
to  a base  cl  ass,  then  the  overridden  version  of  thefunction  may 
return  a poi  nter  or  reference  to  a class  derived  from  what  the  base 
returns.  For  example: 

//:  C15 : VariantReturn . cpp 

//  Returning  a pointer  or  reference  to  a derived 
//  type  during  ovverriding 
#include  <iostream> 

#include  <string> 
using  namespace  std; 

class  PetFood  { 
public : 

virtual  string  foodTypeO  const  = 0; 

}; 


class  Pet  { 
public : 

virtual  string  type()  const  = 0; 
virtual  PetFood*  eats()  = 0; 
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}; 


class  Bird  : public  Pet  { 
public : 

string  type()  const  { return  "Bird";  } 
class  BirdFood  : public  PetFood  { 
public : 

string  foodTypeO  const  { 
return  "Bird  food"; 


//  Upcast  to 
PetFood*  eats 
private : 

BirdFood  bf; 


base 

0 { 


}; 


type: 

return 


&bf;  } 


class  Cat  : public  Pet  { 
public : 

string  type()  const  { return  "Cat";  } 
class  CatFood  : public  PetFood  { 
public : 

string  foodTypeO  const  { return  "Birds";  } 

}; 

//  Return  exact  type  instead: 

CatFood*  eatsO  { return  &cf;  } 
private : 

CatFood  cf; 


int  main  ( ) { 

Bird  b; 

Cat  c; 

Pet*  p [ ] = { &b,  &c,  } ; 

for(int  i = 0;  i < sizeof  p / sizeof  *p;  i++) 
cout  <<  p[i]->type()  <<  " eats  " 

<<  p [ i ] ->eat s ( ) ->f oodType ( ) <<  endl; 

//  Can  return  the  exact  type: 

Cat ::  CatFood*  cf  = c.eatsO; 

Bird :: BirdFood*  bf; 

//  Cannot  return  the  exact  type: 

// ! bf  = b . eats ( ) ; 

//  Must  downcast: 

bf  = dynamic_cast<Bird:  : BirdFood*> (b . eats ( ) ) ; 

} ///:- 


694 


Thinking  in  C+  + 


www.BruceEckel.com 


The  Pet::eats(  )mennber  function  returns  a pointertoa  PetFood  In 
Bird,  this  member  function  is  overloaded  exactly  as  in  the  base 
class,  including  the  return  type.  That  is,  Bird::eats(  >jpcaststhe 

BirdFoodto  a PetFood 

But  i n C at  the  retu  rn  type  of  eats( ) i s a poi  nter  to  C atFood  a type 
derived  from  PetFood  Thefact  that  the  return  type  is  inherited 
from  the  return  type  of  the  base-class  function  is  the  only  reason 
this  compiles.  That  way,  the  contract  is  still  fulfilled;  eats(  )always 
returns  a PetFood  poi  nter. 

If  you  think  polymorphically,  thisdoesn't  seem  necessary.  Why  not 
just  upcast  all  the  return  types  to  PetFood*  just  as  Bird::eats(  )did? 
This  istypically  a good  solution,  but  at  the  end  of  main( ) you  see 
the  d ifference:  C at::eats(  )can  retu  rn  the  exact  type  of  PetFood 
whereas  the  return  value  of  Bird ::eats(  )must  be  downcast  to  the 
exact  type. 

So  being  able  to  return  the  exact  type  is  a little  more  general,  and 
doesn't  lose  the  specific  type  information  by  automatically 
upcasting.  However,  returning  the  base  type  will  generally  solve 
your  problems  so  this  is  a rather  specialized  feature. 


virtual  functions  & constructors 

When  an  object  containing  virtual  functions  is  created,  itsVPTR 
must  deinitialized  to  point  to  the  proper  VTA  BLE.  This  must  be 
done  before  there's  any  possibility  of  calling  a virtual  function.  As 
you  might  guess,  because  the  constructor  has  the  job  of  bringing  an 
object  into  existence,  it  is  also  the  constructor's  job  to  set  up  the 
VPTR.  The  compiler  secretly  inserts  code  into  the  beginning  of  the 
constructor  that  initializes theVPTR.  And  asdescribed  in  Chapter 
14,  if  you  don't  explicitly  create  a constructor  for  a class,  the 
compiler  will  synthesize  one  for  you.  If  the  class  has  virtual 
functions,  the  synthesized  constructor  will  include  the  proper 
VPTR  initialization  code.  This  has  several  implications. 
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Thefi  rst  concerns  efficiency.  The  reason  for  inlinefu notions  is  to 
reduce  the  cal  ling  overhead  for  small  functions.  If  C++didn't 
provide  inlinefunctions,  the  preprocessor  might  be  used  to  create 
these  "macros."  H owever,  the  preprocessor  has  no  concept  of 
access  or  classes,  and  therefore  couldn't  be  used  to  create  member 
function  macros.  In  addition,  with  constructors  that  must  have 
hidden  code  inserted  by  the  compiler,  a preprocessor  macro 
wouldn't  work  at  all. 

You  must  be  aware  when  hunting  for  efficiency  holes  that  the 
compiler  is  inserting  hidden  code  into  your  constructor  function. 
Not  only  must  it  initialize  the  VPTR,  it  must  also  check  the  value  of 
this(in  case  the  operatornew  returns  zero)  and  call  base-class 
constructors.  Taken  together,  this  code  can  impact  what  you 
thought  was  a tiny  inline  function  call.  In  particular,  the  size  of  the 
constructor  may  overwhelm  the  savings  you  get  from  reduced 
function-call  overhead.  If  you  make  a lot  of  inline  constructor  cal  Is, 
your  code  size  can  grow  without  any  benefits  in  speed. 

Of  course,  you  probably  won't  make  all  tiny  constructors  non- 
i nl  i ne  right  away,  because  they're  much  easier  to  write  as  i nl  i nes. 
But  when  you're  tuning  your  code,  remember  to  consider  removing 
the  i nl  i ne  constructors. 

Order  of  constructor  calls 

The  second  interesting  facet  of  constructors  and  virtual  functions 
concerns  the  order  of  constructor  cal  I s and  the  way  vi  rtual  cal  I s are 
made  within  constructors. 

All  base-class  constructors  are  always  cal  led  in  the  constructor  for 
an  inherited  class.  This  makes  sense  because  the  constructor  has  a 
special  job:  to  see  that  the  object  is  built  properly.  A derived  class 
has  access  only  to  its  own  members,  and  not  those  of  the  base  class. 
Only  the  base-class  constructor  can  properly  initialize  its  own 
elements.  Therefore  it's  essential  that  all  constructors  get  called; 
otherwise  the  entire  object  wouldn't  deconstructed  properly.  That's 
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why  the  compiler  enforces  a constructor  cal  I for  every  portion  of  a 
derived  class.  It  will  call  the  default  constructor  if  you  don't 
explicitly  call  a base-class  constructor  in  the  constructor  initializer 
1 1st.  If  there  is  no  default  constructor,  the  compi  ler  wi  1 1 complai  n. 

The  order  of  the  constructor  cal  Is  is  i mportant.  When  you  i nherit, 
you  know  all  about  the  base  cl  ass  and  can  access  any  publicand 
protectedmembers  of  the  base  class.  This  means  you  must  be  able 
to  assume  that  all  the  members  of  the  base  cl  ass  are  valid  when 
you're  in  the  derived  class.  In  a normal  member  function, 
construction  has  already  taken  place,  so  all  the  members  of  all  parts 
of  the  object  have  been  built.  I nsidethe  constructor,  however,  you 
must  be  able  to  assume  that  all  members  that  you  use  have  been 
built.  The  only  way  to  guarantee  this  is  for  the  base-class 
constructor  to  be  cal  led  first.  Then  when  you're  in  the  derived-class 
constructor,  all  the  members  you  can  access  in  the  base  cl  ass  have 
been  initialized.  "Knowing  all  members  are  valid"  insidethe 
constructor  is  also  the  reason  that,  whenever  possible,  you  should 
initialize  all  member  objects  (that  is,  objects  placed  in  the  class 
using  composition)  in  the  constructor  initializer  list.  If  you  follow 
this  practice,  you  can  assume  that  all  base  cl  ass  members  and 
member  objects  of  the  current  object  have  been  initialized. 

Behavior  of  virtual  functions  inside 
constructors 

Thehierarchy  of  constructor  calls  brings  up  an  interesting 
di  lemma.  What  happens  if  you're  i nside  a constructor  and  you  cal  I 
a virtual  function?  I nside  an  ordinary  member  function  you  can 
imaginewhat  will  happen  - the  virtual  call  is  resolved  at  runtime 
because  the  object  cannot  know  whether  it  belongs  to  the  cl  ass  the 
member  function  is  in,  or  some  cl  ass  derived  from  it.  For 
consistency,  you  mightthink  this  is  what  should  happen  inside 
constructors. 
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This  is  not  the  case,  if  you  caii  a virtuai  function  inside  a 
constructor,  oniytheiocai  version  of  the  function  is  used.  That  is, 
the  vi  rtuai  mechani sm  doesn't  work  withi  n the  constructor. 

This  behavior  makes  sense  for  two  reasons.  Conceptuaiiy,  the 
constructor's  job  isto  bring  the  object  into  existence  (which  is 
hardiy  an  ordinary  feat),  inside  any  constructor,  the  object  may 
oniy  be  parti aiiy  formed  - you  can  oniy  know  that  the  base-ciass 
objects  have  been  initiaiized,  but  you  cannot  know  which  dasses 
are  inherited  from  you.  A virtuai  function  caii,  however,  reaches 
"forward"  or  "outward"  into  the  inheritance  hierarchy,  itcaiisa 
function  in  a derived  dass.  if  you  couid  do  this  inside  a constructor, 
you'd  be  caiiing  a function  that  might  manipuiate  members  that 
hadn't  been  initiaiized  yet,  a sure  recipe  for  disaster. 

The  second  reason  is  a mechani cai  one.  When  a constructor  is 
caiied,  one  of  the  first  things  it  does  is  initiaiizeitsVPTR.  However, 
it  can  oniy  know  that  it  isof  the  "current"  type-  the  type  the 
constructor  was  written  for.  The  constructor  code  is  compieteiy 
ignorant  of  whether  or  not  the  object  is  i n the  base  of  another  dass. 
When  thecompiier  generates  codefor  that  constructor,  it  generates 
codefor  a constructor  of  that  ciass,  not  a base  ciass  and  not  a ciass 
derived  from  it  (because  a ciass  can't  know  who  inherits  it).  So  the 
VPTR  it  uses  must  be  for  the  VTA  BLE  of  that  ciass.  TheVPTR 
remai  ns  i nitiai  ized  to  that  VTA  BLE  for  the  rest  of  the  object's 
i ifeti  me  unless  this  isn't  the  iast  constructor  cai i . if  a more-derived 
constructor  is  caiied  afterwards,  that  constructor  sets  the  VPTR  to 
/ts  VTA  BLE,  and  soon,  untii  the  iast  constructor  finishes.  The  state 
of  the  VPTR  is  determined  by  the  constructor  that  is  caiied  iast. 

This  isanother  reason  why  the  constructors  are  caiied  in  order  from 
base  to  most-derived. 

But  whiieaii  this  series  of  constructor  cai  is  is  taking  pi  ace,  each 
constructor  has  set  the  VPTR  to  its  own  VTA  BLE.  if  it  uses  the 
virtuai  mechanism  for  function  caiis,  it  wiii  produce  oniy  a caii 
through  itsown  VTABLE,  not  the  most-derived  VTABLE  (aswouid 
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be  the  case  after  all  the  constructors  were  cal  led).  In  addition,  many 
compilers  recognizethat  a virtual  function  call  is  being  made  inside 
a constructor,  and  perform  early  binding  because  they  know  that 
late-binding  will  produceacall  only  to  the  local  function.  In  either 
event,  you  won't  get  the  results  you  might  initially  expect  from  a 
virtual  function  call  inside  a constructor. 


Destructors  and  virtual  destructors 

You  cannot  use  the  virtual  keyword  with  constructors,  but 
destructors  can  and  often  must  be  virtual. 

The  constructor  has  the  special  job  of  putting  an  object  together 
piece- by- piece,  fi  rst  by  calling  the  base  constructor,  then  the  more 
derived  constructors  in  order  of  inheritance  (it  must  also  call 
member-object  constructors  along  the  way).  Similarly,  the 
destructor  has  a special  job:  it  must  disassemble  an  object  that  may 
belong  to  a hierarchy  of  classes.  To  do  this,  the  compiler  generates 
codethat  calls  all  the  destructors,  but  in  the  rei/erse  order  that  they 
are  cal  led  by  the  constructor.  That  is,  the  destructor  starts  at  the 
most-derived  class  and  works  its  way  down  to  the  base  class.  This 
isthe  safe  and  desirablethingtodo  because  the  current  destructor 
can  always  know  that  the  base-class  members  are  al  ive  and  active. 

If  you  need  to  cal  I a base-class  member  function  inside  your 
destructor,  it  is  safe  to  do  so.  Thus,  the  destructor  can  perform  its 
own  cleanup,  then  call  the  next-down  destructor,  which  will 
perform  /tsown  cleanup,  etc.  Each  destructor  knows  what  its  class 
is  derived  from,  but  not  what  is  derived  from  it. 

You  should  keep  in  mind  that  constructors  and  destructors  are  the 
only  places  where  this  hierarchy  of  calls  must  happen  (and  thusthe 
proper  hierarchy  is  automatically  generated  by  the  compiler).  In  all 
other  functions,  only  t/iaf  function  will  be  called  (and  not  base-class 
versions),  whether  it's  virtual  or  not.  The  only  way  for  base-class 
versi  ons  of  the  same  fu  ncti  on  to  be  cal  I ed  i n ord  i nary  fu  ncti  ons 
(virtual  or  not)  is  if  you  explicitly  cbW  that  function. 
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Normally,  the  action  of  the  destructor  is  quite  adequate.  But  what 
happens  if  you  want  to  manipulate  an  object  through  a pointer  to 
its  base  cl  ass  (that  is,  manipulate  the  object  through  its  generic 
interface)?  This  activity  isa  major  objectivein  object-oriented 
programming.  The  problem  occurs  when  you  wanttodeletea 
pointer  of  this  type  for  an  object  that  has  been  created  on  the  heap 
with  new.  If  the  pointer  isto  the  base  class,  the  compiler  can  only 
know  to  call  the  base-class  version  of  the  destructor  during  delete 
Sou nd  fami  I i ar?  Thi s i s the  same  probi em  that  vi  rtual  f u ncti  ons 
were  created  to  solvefor  the  general  case.  Fortunately,  virtual 
functions  work  for  destructors  as  they  do  for  all  other  functions 
except  constructors. 

//:  C15 : VirtualDestructors . cpp 

//  Behavior  of  virtual  vs.  non-virtual  destructor 
#include  <iostream> 
using  namespace  std; 

class  Basel  { 
public : 

-Basel  0 { cout  <<  " -Basel () \n" ; } 

}; 


class  Derivedl  : public  Basel  { 
public : 

-Derivedl 0 { cout  <<  "-Derivedl () \n" ; } 

}; 


class  Base2  { 
public : 

virtual  -Base2()  { cout  <<  " -Base2 ( ) \n" ; } 

}; 


class  Derived2  : public  Base2  { 
public : 

-Derived2()  { cout  <<  "-Derived2 ( ) \n" ; } 

}; 


int  main  ( ) { 

Basel*  bp  = new  Derivedl;  //  Upcast 
delete  bp; 

Base2*  b2p  = new  Derived2;  //  Upcast 
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delete  b2p; 

} III-.- 

When  you  run  the  program,  you'll  see  that  delete  bponly  callsthe 
base-class  destructor,  whiledelete  b2pcal  Is  the  derived-class 
destructor  followed  by  the  base-class  destructor,  which  isthe 
behavior  we  desire.  Forgetting  to  make  a destructor  virtual  is  an 
insidious  bug  because  it  often  doesn't  directly  affect  the  behavior  of 
your  program,  but  it  can  quietly  introduce  a memory  leak.  Also,  the 
fact  that  some  destruction  isoccurring  can  further  mask  the 
problem. 

Even  though  the  destructor,  I ike  the  constructor,  is  an 
"exceptional"  function,  it  is  possible  for  the  destructor  to  be  virtual 
because  the  object  already  knows  what  type  it  is  (whereas  it  doesn't 
during  construction).  Once  an  object  has  been  constructed,  its 
VPTR  is  initialized,  so  virtual  function  calls  can  take  place. 

Pure  virtual  destructors 

While  pure  virtual  destructors  are  legal  in  Standard  C-H-,  there  is 
an  added  constraint  when  using  them:  you  must  provide  a function 
body  for  the  pure  virtual  destructor.  This  seems  counter  intuitive; 
how  can  a virtual  function  be  "pure"  if  it  needs  a function  body? 

But  if  you  keep  in  mind  that  constructors  and  destructors  are 
special  operations  it  makes  more  sense,  especially  if  you  remember 
that  all  destructorsin  a class  hierarchy  are  always  cal  led.  If  you 
cou/d  leave  off  the  definition  for  a pure  virtual  destructor,  what 
function  body  would  be  called  during  destruction?  Thus,  it's 
absolutely  necessary  that  the  compiler  and  linker  enforce  the 
existence  of  a function  body  for  a pure  virtual  destructor. 

If  it's  pure,  but  it  has  to  have  a function  body,  what's  the  value  of 
it?  The  only  difference  you'll  see  between  the  pure  and  non-pure 
virtual  destructor  isthat  the  pure  virtual  destructor  does  cause  the 
base  class  to  be  abstract,  so  you  cannot  create  an  object  of  the  base 
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class  (although  this  would  also  be  true  if  any  other  mennber 
function  of  the  base  class  were  pure  virtual). 

Things  are  a bit  confusing,  however,  when  you  inherit  a class  from 
one  that  contai  ns  a pure  vi  rtual  destructor.  U nl  i ke  every  other  pure 
virtual  function,  you  are  not  required  to  provide  a definition  of  a 
pure  virtual  destructor  in  the  derived  class.  The  fact  that  the 
following  compiles  and  I inks  is  the  proof: 

//:  C15 : UnAbstract . cpp 
//  Pure  virtual  destructors 
//  seem  to  behave  strangely 

class  AbstractBase  { 
public : 

virtual  -AbstractBase ( ) = 0; 

}; 

AbstractBase :: -AbstractBase  ( ) {} 

class  Derived  : public  AbstractBase  { } ; 

//  No  overriding  of  destructor  necessary? 

int  mainO  { Derived  d;  } ///:- 

Normally,  a pure  virtual  function  in  a base  cl  ass  would  cause  the 
derived  class  to  be  abstract  unless  it  (and  all  other  pure  virtual 
functions)  is  given  a definition.  But  here,  this  seems  not  to  be  the 
case.  H owever,  remember  that  the  compiler  automatically  creates  a 
destructor  definition  for  every  class  if  you  don't  create  one.  That's 
what's  happening  here-  the  base  cl  ass  destructor  is  being  quietly 
overridden,  and  thus  the  definition  isbeing  provided  by  the 
compiler  and  Derivedis  not  actually  abstract. 

This  brings  up  an  interesting  question:  What  isthepointof  a pure 
virtual  destructor?  Uni  ike  an  ordinary  pure  virtual  function,  you 
mtystgiveitafunction  body.  In  a derived  class,  you  aren't  forced  to 
provide  a defi  nition  si  nee  the  compi  ler  synthesizes  the  destructor 
for  you.  So  what's  the  difference  between  a regular  virtual 
destructor  and  a pure  virtual  destructor? 
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The  only  distinction  occurs  when  you  have  a cl  ass  that  only  hasa 
single  pure  virtual  function:  the  destructor.  In  this  case,  the  only 
effect  of  the  purity  of  the  destructor  is  to  prevent  the  instantiation 
of  the  base  cl  ass.  If  there  were  any  other  pure  virtual  functions, 
they  would  prevent  the  instantiation  of  the  base  class,  but  if  there 
are  no  others,  then  the  pure  virtual  destructor  will  do  it.  So,  while 
the  addition  of  a virtual  destructor  is  essential,  whether  it's  pure  or 
not  isn't  so  important. 

When  you  run  thefollowing  example,  you  can  see  that  the  pure 
virtual  function  body  is  called  after  the  derived  class  version,  just 
as  with  any  other  destructor: 

// : C15 : PureVirtualDestructors . cpp 
//  Pure  virtual  destructors 
//  require  a function  body 
#include  <iostream> 
using  namespace  std; 

class  Pet  { 
public : 

virtual  ~Pet()  = 0; 

}; 


Pet : : -Pet  ( ) { 

cout  <<  "~PetO"  <<  endl; 

} 

class  Dog  : public  Pet  { 
public : 

-DogO  { 

cout  <<  "~DogO"  <<  endl; 


}; 


int  main  ( ) { 

Pet*  p = new  Dog;  //  Upcast 
delete  p;  //  Virtual  destructor  call 
} ///:- 
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Asa  guideline,  any  time  you  havea  virtual  function  in  a class,  you 
should  immediately  add  a virtual  destructor  (even  if  it  does 
nothing).  This  way,  you  ensure  against  any  surprises  later. 

Virtuals  in  destructors 

There's  something  that  happens  during  destruction  that  you  might 
not  immediately  expect.  If  you're  inside  an  ordinary  member 
function  and  you  call  a virtual  function,  that  function  iscalled 
using  the  late-binding  mechanism.  This  is  not  true  with  destructors, 
virtual  or  not.  Inside  a destructor,  only  the  "local"  version  of  the 
member  function  iscalled;  the  virtual  mechanism  is  ignored. 

// : C15 : VirtualsInDestructors . cpp 
//  Virtual  calls  inside  destructors 
#include  <iostream> 
using  namespace  std; 

class  Base  { 
public : 

virtual  -Base ( ) { 

cout  <<  "Basel  0\n"; 

f 0 ; 


virtual  void  f()  { cout  <<  "Base : : f ( ) \n" ; } 

}; 


class  Derived  : public  Base  { 
public : 

-Derived  0 { cout  <<  "-Derived () \n" ; } 

void  f()  { cout  <<  "Derived :: f 0 \n" ; } 


int  main  ( ) { 

Base*  bp  = new  Derived;  //  Upcast 
delete  bp; 

} ///:- 

During  the  destructor  call.  Derived  :rf(  )s  not  called,  even  though 
f(  )isvirtual. 
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Why  is  this?  Suppose  the  virtual  mechanism  wereused  insidethe 
destructor.  Then  it  would  be  possible  for  the  virtual  call  to  resolve 
to  a function  that  was  "farther  out"  (more  derived)  on  the 
inheritance  hierarchy  than  the  current  destructor.  But  destructors 
are  cal  led  from  the  "outside  in"  (from  the  most-derived  destructor 
down  to  the  base  destructor),  so  the  actual  function  called  would 
rely  on  portions  of  an  object  that  have  already  been  destroyed'. 

Instead,  thecompiler  resolves  the  cal  I sat  compile-time  and  calls 
only  the  "local"  version  of  thefunction.  Notice  that  the  same  is  true 
for  the  constructor  (as  described  earlier),  but  in  the  constructor's 
case  the  type  information  wasn't  available,  whereas  in  the 
destructor  the  information  (that  is,  theVPTR)  is  there,  but  is  isn't 
reliable. 

Creating  an  object-based  hierarchy 

An  issue  that  has  been  recurring  throughoutthis  book  during  the 
demonstration  of  the  container  classes  Stack  and  Stash  is  the 
"ownership  problem."  The  "owner"  refers  to  who  or  what  is 
responsible  for  calling  deletefor  objects  that  have  been  created 
dynamically  (using  new).  The  problem  when  using  containers  is 
that  they  need  to  be  flexible  enough  to  hold  different  types  of 
objects.  To  do  this,  the  containers  have  held  void  pointers  and  so 
they  haven't  known  the  type  of  object  they've  held.  Deleting  a void 
pointer  doesn't  cal  I the  destructor,  so  the  container  couldn't  be 
responsible  for  cleaning  up  its  objects. 

One  solution  was  presented  in  the  example  C 14:1  nheritStack.cpp 
in  which  the  Stack  was  inherited  into  a new  class  that  accepted  and 
produced  only  string  pointers.  Si  nee  it  knew  that  it  could  hold  only 
pointerstostringobjects,  it  could  properly  del ete  them.  This  was  a 
nice  solution,  but  it  requires  you  to  inherit  a new  container  cl  ass  for 
each  type  that  you  want  to  hold  in  the  container.  (Although  this 
seems  tedious  now,  it  will  actually  work  quite  well  in  Chapter  16, 
when  templates  are  introduced.) 
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The  problem  is  that  you  want  the  container  to  hold  more  than  one 
type,  but  you  don'twantto  use  void  pointers.  Another  solution  is 
to  use  polymorphism  by  forcing  all  the  objects  held  in  the  container 
to  be  inherited  from  the  same  base  cl  ass.  That  is,  the  container 
holds  the  objects  of  the  base  class,  and  then  you  can  call  virtual 
functions-  in  particular,  you  can  call  virtual  destructors  to  solve 
the  ownership  problem. 

This  solution  uses  what  is  referred  to  as  a singly-rooted  hierarchy  or 
an  object-based  hierarchy  (because  the  root  class  of  the  hierarchy  is 
usually  named  "Object”).  It  turns  out  that  there  are  many  other 
benefits  to  using  a singly-rooted  hierarchy;  in  fact,  every  other 
object-oriented  language  but  C-H-enforces  the  use  of  such  a 
hierarchy  - when  you  create  a class,  you  are  automatically 
inheriting  it  directly  or  indirectly  from  a common  base  class,  a base 
class  that  was  estabi  ished  by  the  creators  of  the  language.  I n C-H-,  it 
was  thought  that  the  enforced  use  of  this  common  base  cl  ass  would 
cause  too  much  overhead,  so  it  was  left  out.  However,  you  can 
choose  to  usea  common  base  cl  ass  in  your  own  projects,  and  this 
subject  will  be  examined  further  in  Volume  2 of  this  book. 

To  solve  the  ownership  problem,  wecan  create  an  extremely  simple 
Objectfor  thebaseclass,  which  contains  only  a virtual  destructor. 
The  Stack  can  then  hold  classes  inherited  from  Object 

//:  C15:OStack.h 

//  Using  a singly-rooted  hierarchy 
#ifndef  OSTACK_H 
#define  OSTACK_H 

class  Object  { 
public : 

virtual  -Object ()  = 0; 

}; 


//  Required  definition: 
inline  Ob ject : : -Ob ject  ( ) {} 

class  Stack  { 
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struct  Link  { 

Object*  data; 

Link*  next; 

Link (Object*  dat.  Link*  nxt)  : 
data(dat),  next  (nxt)  {} 

}*  head; 
public : 

Stack ( ) : head ( 0 ) { } 

-Stack ( ) { 

while (head) 
delete  pop  ( ) ; 

} 

void  push (Object*  dat)  { 

head  = new  Link (dat,  head); 

} 

Object*  peekO  const  { 

return  head  ? head->data  : 0; 

} 

Object*  pop ( ) { 

if (head  ==  0)  return  0; 

Object*  result  = head->data; 
Link*  oldHead  = head; 
head  = head->next; 
delete  oldHead; 
return  result; 


}; 

#endif  //  OSTACK_H  ///:- 

To  simplify  things  by  keeping  everything  in  the  header  file,  the 
(required)  definition  for  the  pure  virtual  destructor  is  ini  ined  into 
the  header  file,  and  pop(  )(which  might  be  considered  too  large  for 
inlining)  isalso  inlined. 

Link  objects  now  hold  pointerstoObjectrather  than  void  pointers, 
and  the  Stack  will  only  accept  and  return  Object  pointers.  Now 
Stackismuch  more  flexible,  since  it  will  hold  lots  of  different  types 
but  w i 1 1 al  so  destroy  any  objects  that  are  I eft  on  the  Stack  The  new 
limitation  (which  will  be  finally  removed  when  templates  are 
applied  to  the  problem  in  Chapter  16)  isthat  anything  that  is  placed 
on  the  Stack  must  be  inherited  from  Object  That's  fine  if  you  are 
starting  your  cl  ass  from  scratch,  but  what  if  you  already  have  a 


15:  Polymorphism  & Virtual  Functions 


707 


class  such  as  string  that  you  want  to  be  able  to  put  onto  the  Stack? 
In  this  case,  the  new  class  must  be  both  astringand  an  Object 
which  means  it  must  be  inherited  from  both  classes.  This  is  called 
multiple  inheritancean6  it  is  the  subject  of  an  entire  chapter  in 
Volume2of  this  book  (downloadable from  www.BruceEckel.com). 
When  you  read  that  chapter,  you'll  see  that  multiple  inheritance 
can  be  fraught  with  complexity,  and  is  a feature  you  should  use 
sparingly.  In  this  situation,  however,  everything  is  simple  enough 
that  we  don't  tri  p across  any  mu  Iti  pi  e i nheritance  pi tfal  I s: 

//:  C15 : OStackTest . cpp 
//{T}  OStackTest . cpp 
#include  "OStack.h" 

#include  ".. /require . h" 

#include  <fstream> 

#include  <iostream> 

#include  <string> 
using  namespace  std; 

//  Use  multiple  inheritance.  We  want 
//  both  a string  and  an  Object: 

class  MyString:  public  string,  public  Object  { 
public : 

-MyString 0 { 

cout  <<  "deleting  string:  " <<  *this  <<  endl; 

} 

MyString ( string  s)  : string (s)  {} 

}; 

int  main(int  argc,  char*  argv [ ] ) { 

requireArgs (argc,  1);  //  File  name  is  argument 
ifstream  in(argv[l]); 
assure (in,  argv[l]); 

Stack  textlines; 
string  line; 

//  Read  file  and  store  lines  in  the  stack: 
while (getline (in,  line)) 

textlines . push (new  MyString ( line ) ) ; 

//  Pop  some  lines  from  the  stack: 

MyString*  s; 

for(int  i = 0;  i < 10;  itt)  { 

if ( ( s= (MyString* ) text lines . pop ()) ==0 ) break; 
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cout  <<  *s  <<  endl; 
delete  s; 


} 

cout  <<  "Letting  the  destructor  do  the  rest:" 

<<  endl; 

} ///:- 

Although  this  is  similar  to  the  previous  version  of  the  test  program 
for  Stack,  you'll  notice  that  only  10  elements  are  popped  from  the 
stack,  which  means  there  are  probably  some  objects  remaining. 
Because  the  Stack  knows  that  it  holdsObjecfe,  thedestructor  can 
properly  clean  things  up,  and  you'll  see  this  in  theoutput  of  the 
program,  si  nee  the  M yStri  ngobjects  pri  nt  messages  as  they  are 
destroyed. 

Creating  contai ners that  hold  Object  is  not  an  unreasonable 
approach  - /fyou  have  a singly-rooted  hierarchy  (enforced  either 
by  the  language  or  by  the  requirement  that  every  class  inherit  from 
0 bjec^.  I n that  case,  everything  is  guaranteed  to  be  an  0 bjectand 
so  it's  not  very  complicated  to  use  the  contai  ners.  In  C++,  however, 
you  cannot  expect  thisfrom  every  class,  so  you're  bound  to  trip 
over  mu  I ti  p I e i n her i tance  i f you  take  th  i s ap p roach . Y ou ' 1 1 see  i n 
Chapter  16that  templates  solve  the  problem  in  a much  simpler  and 
more  el  egant  fash  ion. 


Operator  overloading 

You  can  make  operators  virtual  just  likeother  member  functions. 
Implementing  virtual  operators  often  becomes  confusing,  however, 
because  you  may  be  operating  on  two  objects,  both  with  unknown 
types.  This  is  usually  the  case  with  mathematical  components  (for 
which  you  often  overload  operators).  For  example,  consider  a 
system  that  deals  with  matrices,  vectors  and  scalar  values,  all  three 
of  which  are  derived  from  class  Math: 

//:  C15 : OperatorPolymorphism. epp 
//  Polymorphism  with  overloaded  operators 
#include  <iostream> 
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using  namespace  std; 


class  Matrix; 
class  Scalar; 
class  Vector; 

class  Math  { 
public : 

virtual  Math&  operator* (Math&  rv)  = 0; 

virtual  Math&  multiply (Matrix* ) = 0; 

virtual  Math&  multiply (Scalar* ) = 0; 

virtual  Math&  multiply (Vector* ) = 0; 

virtual  ~Math()  {} 

}; 

class  Matrix  : public  Math  { 
public : 

Math&  operator* (Math&  rv)  { 

return  rv. multiply (this) ; //  2nd  dispatch 

} 

Math&  multiply (Matrix* ) { 

cout  <<  "Matrix  * Matrix"  <<  endl; 
return  *this; 

} 

Math&  multiply (Scalar* ) { 

cout  <<  "Scalar  * Matrix"  <<  endl; 
return  *this; 

} 

Math&  multiply (Vector* ) { 

cout  <<  "Vector  * Matrix"  <<  endl; 
return  *this; 

} 

}; 

class  Scalar  : public  Math  { 
public : 

Math&  operator* (Math&  rv)  { 

return  rv. multiply (this) ; //  2nd  dispatch 

} 

Math&  multiply (Matrix* ) { 

cout  <<  "Matrix  * Scalar"  <<  endl; 
return  *this; 

} 

Math&  multiply (Scalar* ) { 

cout  <<  "Scalar  * Scalar"  <<  endl; 
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return  *this; 


} 

Math&  multiply (Vector* ) { 

cout  <<  "Vector  * Scalar"  <<  endl; 
return  *this; 

} 

}; 

class  Vector  : public  Math  { 
public : 

Math&  operator* (Math&  rv)  { 

return  rv. multiply (this) ; //  2nd  dispatch 

} 

Math&  multiply (Matrix* ) { 

cout  <<  "Matrix  * Vector"  <<  endl; 
return  *this; 

} 

Math&  multiply (Scalar* ) { 

cout  <<  "Scalar  * Vector"  <<  endl; 
return  *this; 

} 

Math&  multiply (Vector* ) { 

cout  <<  "Vector  * Vector"  <<  endl; 
return  *this; 

} 

}; 

int  main  ( ) { 

Matrix  m;  Vector  v;  Scalar  s; 

Math*  math[]  = { &m,  &v,  &s  }; 

for(int  1=0;  1 < 3;  1++) 
for(int  j = 0;  j < 3;  j++)  { 

Math&  ml  = *math[i]; 

Math&  m2  = *math[j]; 
ml  * m2; 

} 

} ///:- 

For  simplicity,  only  the operator*has  been  overloaded.  The  goal  is 
to  be  able  to  multiply  any  two  M ath  objects  and  produce  the 
desired  result-and  notethat  multiplying  a matrix  by  a vector  isa 
very  different  operation  than  multiplying  a vector  by  a matrix. 
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The  problem  is  that,  in  main( ) the  express!  on  ml*  m2contains 
two  upcast  M ath  references,  and  thus  two  objects  of  unknown 
type.  A virtual  function  is  only  capable  of  making  a single  dispatch 
- that  is,  determining  the  type  of  one  unknown  object.  To 
determine  both  types  a technique  cal  led  multiple  dispatching  isused 
in  thisexample,  whereby  what  appears  to  be  a single  virtual 
function  call  results  in  a second  virtual  call.  By  the  time  this  second 
call  is  made,  you've  determined  both  types  of  object,  and  can 
perform  the  proper  activity.  It's  not  transparent  at  first,  but  if  you 
stareattheexampleforawhileit  should  begin  to  make  sense.  This 
topic  is  explored  in  moredepth  in  the  Design  Patterns  chapter  i n 
Volume 2,  which  you  can  download  at  www.BruceEckd.com. 


Downcasting 

As  you  might  guess,  si  nee  there's  such  a thing  as  upcasting - 
moving  up  an  inheritance  hierarchy -there  should  also  be 
downcasting  to  move  down  a hierarchy.  But  upcasti  ng  is  easy  si  nee 
as  you  move  up  an  inheritance  hierarchy  the  classes  always 
converge  to  more  general  classes.  That  is,  when  you  upcast  you  are 
always  clearly  derived  from  an  ancestor  class  (typically  only  one, 
except  in  the  case  of  multiple  inheritance)  but  when  you  downcast 
there  are  usually  several  possibilities  that  you  could  cast  to.  More 
specifically,  aCircleisatype of  Shape(that'stheupcast),  but  if 
you  try  to  downcast  a Shapeit  could  be  a C irde  Square  T riangle 
etc.  So  the  dilemma  is  figuring  out  a way  to  safely  downcast.  (But 
an  even  more  important  issue  is  asking  yourself  why  you're 
downcasting  in  the  first  pi  ace  instead  of  just  using  polymorphism 
to  automati  cal  ly  fi  gu re  out  the  correct  type.  The  avoi  dance  of 
downcasting  iscovered  in  Volu  me  2 of  this  book.) 

C++provides  a special  explicit  cast  {Introduced  in  Chapters)  called 
dynamic_castthat  is  a type-safe  downcast  operation.  When  you  use 
dynamic_castto  try  to  cast  down  to  a particular  type,  the  return 
valuewill  bea  pointer  to  the  desired  type  only  if  the  cast  is  proper 
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and  successful,  otherwise  it  will  return  zero  to  indicate  that  this 
was  not  the  correct  type.  Here's  a mininnal  example: 


//:  C15 : DynamicCast . cpp 
#include  <iostream> 
using  namespace  std; 


class  Pet  { public:  virtual  ~Pet(){}}; 
class  Dog  : public  Pet  {}; 
class  Cat  : public  Pet  {}; 

int  main  ( ) { 

Pet*  b = new  Cat;  //  Upcast 
//  Try  to  cast  it  to  Dog*: 

Dog*  dl  = dynamic_cast<Dog*> (b) ; 

//  Try  to  cast  it  to  Cat*: 

Cat*  d2  = dynamic_cast<Cat*> (b) ; 
cout  <<  "dl  = " <<  (long)dl  <<  endl; 
cout  <<  "d2  = " <<  (long)d2  <<  endl; 

} ///:- 

When  you  usedynamic_castyou  must  be  working  with  a true 
polymorphic  hierarchy -one  with  virtual  functions-  because 
dynamic_castuses  information  stored  in  the  VTABLE  to  determine 
the  actual  type.  Here,  the  base  cl  ass  contains  a virtual  destructor 
and  that  suffi ces.  I n mai n( ) a C at  poi nter  i s u pcast  to  a Pet  and 
then  a downcast  is  attempted  to  both  a D og  poi  nter  and  a C at 
pointer.  Both  pointers  are  printed,  and  you'll  see  when  you  run  the 
program  that  the  incorrect  downcast  produces  a zero  result.  Of 
course,  whenever  you  downcast  you  are  responsible  for  checking  to 
make  su  re  that  the  resu  1 1 of  the  cast  i s nonzero.  A I so,  you  shou  I d 
not  assume  that  the  poi  nter  will  be  exactly  the  same,  because 
sometimes  pointer  adjustments  take  place  during  upcasting  and 
downcasting  (in  particular,  with  multiple  inheritance). 

A dynamic_castrequiresa  little  bit  of  extra  overhead  to  run;  not 
much,  but  if  you're  doing  a lotof  dyn ami c_ casing  (in  which  case 
you  should  be  seriously  questioning  your  program  design)  this 
may  become  a performance  issue.  I n some  cases  you  may  know 
something  special  during  downcasting  that  allows  you  to  say  for 
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sure  what  type  you're  dealing  with,  in  which  case  the  extra 
overhead  of  the  dynamic_castbecomes  unnecessary,  and  you  can 
useastatic_castinstead.  Here's  how  it  might  work: 

// : C15 : StaticHierarchyNavigation . cpp 
//  Navigating  class  hierarchies  with  static_cast 
#include  <iostream> 

#include  <typeinfo> 
using  namespace  std; 

class  Shape  { public:  virtual  -Shape  ()  {};  }; 

class  Circle  : public  Shape  {}; 
class  Square  : public  Shape  {}; 
class  Other  { } ; 

int  main ( ) { 

Circle  c; 

Shape*  s = &c;  //  Upcast:  normal  and  OK 
//  More  explicit  but  unnecessary: 
s = static_cast<Shape*> (&c)  ; 

//  (Since  upcasting  is  such  a safe  and  common 
//  operation,  the  cast  becomes  cluttering) 

Circle*  cp  = 0; 

Square*  sp  = 0; 

//  Static  Navigation  of  class  hierarchies 
//  requires  extra  type  information: 
if(typeid(s)  ==  typeid(cp))  //  C++  RTTI 
cp  = static_cast<Circle*> (s)  ; 
if(typeid(s)  ==  typeid(sp)) 
sp  = static_cast<Square*> (s)  ; 
if(cp  !=  0) 

cout  <<  "It's  a circle!"  <<  endl; 
if ( sp  ! = 0 ) 

cout  <<  "It's  a square!"  <<  endl; 

//  Static  navigation  is  ONLY  an  efficiency  hack; 

//  dynamic_cast  is  always  safer.  However: 

//  Other*  op  = static_cast<Other*> (s)  ; 

//  Conveniently  gives  an  error  message,  while 
Other*  op2  = (Other*) s; 

//  does  not 

} ///:- 

In  this  program,  a new  feature  is  used  that  is  not  fully  described 
until  Volume  2 of  this  book,  whereachapter  isgiven  to  the  topic: 
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C-H-'s  run-time  type  information  (RTTI)  mechanism.  RTTI  allows  you 
to  discover  type  information  that  has  been  lost  by  upcasting.  The 
dynamic_casts  actually  one  form  of  RTTI.  Here,  thetypeid 
keyword  (declared  in  the  header  file  <typeinfo:i^  is  used  to  detect 
the  types  of  the  poi  nters.  Y ou  can  see  that  the  type  of  the  upcast 
Shapepointer  is  successively  compared  to  a Circle  pointer  and  a 
Square  pointer  to  see  if  there's  a match.  There's  more  to  RTTI  than 
typeid  and  you  can  also  imagine  that  it  would  be  fairly  easy  to 
implement  your  own  type  information  system  using  a virtual 
function. 

A Circleobject  is  created  and  theaddressisupcasttoaShape 
pointer;  the  second  version  of  the  expression  shows  how  you  can 
usestatic_castto  be  more  explicit  about  the  upcast.  However,  since 
an  upcast  is  always  safe  and  it's  a common  thing  to  do,  I consider 
an  explicit  cast  for  upcasting  to  be  cl  uttering  and  unnecessary. 

RTTI  is  used  to  determine  the  type,  and  then  static_  casts  used  to 
perform  the  downcast.  But  notice  that  in  this  design  the  process  is 
effectively  the  same  as  using  dynamic_castdnd  the  client 
programmer  must  do  some  testing  to  discover  the  cast  that  was 
actually  successful.  You'll  typically  want  a situation  that's  more 
deterministic  than  in  the  example  above  before  using  static_cast 
rather  than  dynamic_cast(and,  again,  you  want  to  carefully 
examine  your  design  before  using  dynamic_cast 

If  a class  hierarchy  has  no  virtual  functions  (which  is  a questionable 
design)  or  if  you  have  other  information  that  allows  you  to  safely 
downcast,  it's  a tiny  bit  faster  to  do  the  downcast  statically  than 
with  dynamic_castln  addition,  static_castwon't  allow  you  to  cast 
out  of  the  hierarchy,  as  the  traditional  cast  will,  so  it'ssafer. 
However,  statically  navigating  class  hierarchies  is  always  risky  and 
you  should  usedynamic_castunlessyou  havea  special  situation. 
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Summary 

Polymorphism  - implemented  in  C-H-with  virtual  functions- 
means "different forms."  In  object-oriented  programming,  you 
have  the  same  face  (the  common  i nterface  i n the  base  cl  ass)  and 
different  forms  using  that  face:  the  different  versions  of  the  vi  rtual 
functions. 

You'veseen  in  this  chapter  that  it's  impossible  to  understand,  or 
even  create,  an  example  of  polymorphism  without  using  data 
abstraction  and  inheritance.  Polymorphism  is  a feature  that  cannot 
be  viewed  in  isolation  (I  ikeconstor  a switch  statement,  for 
example),  but  instead  works  only  in  concert,  as  partof  a "big 
picture"  of  class  relationships.  People  are  often  confused  by  other, 
non-object-oriented  featuresof  C-H-,  I ike  overloading  and  default 
arguments,  which  are  someti  mes  presented  as  object-oriented. 
Don't  befooled;  if  it  isn't  late  binding,  it  isn't  polymorphism. 

To  use  polymorphism  - and  thus,  object-oriented  techniques  - 
effectively  in  your  programs  you  must  expand  your  view  of 
programming  to  include  not  just  members  and  messages  of  an 
individual  class,  but  also  the  commonality  among  classes  and  their 
relationships  with  each  other.  Although  this  requires  significant 
effort,  it's  a worthy  struggle,  because  the  results  are  faster  program 
development,  better  code  organization,  extensible  programs,  and 
easier  code  maintenance. 

Polymorphism  completes  the  object-oriented  featuresof  the 
language,  but  there  are  two  more  major  features  in  C-H-:  templates 
(which  are  introduced  in  Chapter  16 and  covered  in  much  more 
detail  in  Volume 2),  and  exception  handling  (which  iscovered  in 
Volume2).Thesefeaturesprovideyou  as  much  increase  in 
programming  power  as  each  of  the  object-oriented  features: 
abstract  data  typing,  inheritance,  and  polymorphism. 
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Exercises 

Solutions  to  selected  exercises  can  be  found  in  the  electronic  document  TheThinking  in  C++ Annotated 
Solution  Guide,  avail  able  for  a small  feefromwww.BruceEckel.com. 

1.  Create  a simple  "shape"  hierarchy:  a base  cl  ass  cal  led 
Shapeand  derived  classes  cal  led  Cirda  Squara  and 
Triangla  In  the  base  class,  make  a virtual  function  called 
draw(  ),and  override  this  in  the  derived  classes.  Make  an 
array  of  pointers  to  Shapaobjectsthat  you  create  on  the 
heap  (and  thus  perform  upcasting  of  the  pointers),  and 
call  draw(  )through  the  base-class  pointers,  to  verify  the 
behavior  of  the  virtual  function.  If  your  debugger 
supports  it,  single-step  through  the  code. 

2.  Modify  Exercise  1 sod  raw  ( )isa  pure  virtual  function. 

T ry  creating  an  object  of  type  Shapa  Try  to  cal  I the  pure 
virtual  function  inside  the  constructor  and  see  what 
happens.  Leaving  it  as  a pure  virtual,  givedraw(  )a 
definition. 

3 . Expand  i ng  on  Exerd  se  2,  create  a f u ncti  on  that  takes  a 
Shapaobject  by  value  and  try  to  upcast  a derived  object  in 
as  an  argument.  See  what  happens.  Fix  the  function  by 
taking  a reference  to  the  Shapaobject. 

4.  Modify  C14:Combi  nad.cppso  that  f( ) is  virtual  in  the 
base  class.  Change  main(  )to  perform  an  upcast  and  a 
virtual  call. 

5.  M odify  InstrumantS.cppby  adding  a virtual  prapara( ) 

function.  Call  prapara(  )insidetuna( ) 

6.  Create  an  inheritance  hierarchy  of  Rodant  M ousa 

G arbil,  H amstar  etc.  I n the  base  class,  provide  methods 
that  are  common  to  all  Rodant,  and  redefine  these  in  the 
derived  classes  to  perform  different  behaviors  depending 
on  the  specific  type  of  Rodant  Create  an  array  of 
pointers  to  Rodant  fill  itwith  different  specific  types  of 
Rodant,  and  call  your  base-class  methods  to  see  what 
happens. 
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7.  Modify  Exercise  6 so  that  you  usea  vector<Rodent*> 
instead  of  an  array  of  pointers.  M ake  sure  that  memory  is 
cleaned  up  properly. 

8.  Starting  with  the  previous  Rodenthierarchy,  inherit 
BlueH  amsteifrom  H amster(yes,  there  is  such  a thing;  I 
had  one  when  I was  a kid),  override  the  base-class 
methods,  and  show  that  the  codethatcallsthe  base-class 
methods  doesn't  need  to  change  in  order  to 
accommodate  the  new  type. 

9.  Starting  with  the  previous  Rodenthierarchy,  add  anon 
virtual  destructor,  create  an  object  of  cl  ass  Hamsterusing 
new,  upcast  the  pointer  to  a Rodent*  and  deletethe 
pointer  to  show  that  it  doesn't  call  all  the  destructors  in 
the  hierarchy.  Change  the  destructor  to  be  virtual  and 
demonstrate  that  the  behavior  is  now  correct. 

10.  Starting  with  the  previous  Rodenthierarchy,  modify 
Rodentso  it  is  a pure  abstract  base  cl  ass. 

11.  C reate  an  ai  r-traffi  c control  system  w ith  base-cl  ass 
Aircraftand  various  derived  types.  Create  a Tower  cl  ass 
with  a vectorcA  ircraft*5that  sends  the  appropriate 
messages  to  the  various  aircraft  under  its  control. 

12.  Create  a model  of  a greenhouse  by  inheriting  various 
typesof  Plantand  building  mechanisms  into  your 
greenhouse  that  take  care  of  the  plants. 

13.  In  Early.cpp  makePeta  pure  abstract  base  class. 

14.  In  AddingVirtuals.cppmakeall  the  member  functions 
of  Pet  pure  victuals,  but  providea  definition  for  name( ) 
FixDogas  necessary,  using  the  base-class  definition  of 
name( ) 

15.  Write  a small  program  to  show  the  difference  between 
calling  a virtual  function  insidea  normal  member 
function  and  calling  a virtual  function  insidea 
constructor.  The  program  should  prove  that  the  two  calls 
produce  different  results. 
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16.  Modify  Vi rtualslnDestructors.cp^y  inheriting  a class 
from  Derived  and  overriding  f(  )and  the  destructor.  In 
main( ) create  and  upcast  an  object  of  your  new  type, 
then  deieteit. 

17.  Take  Exercise  16  and  add  cal  Is  to  f()  in  each  destructor. 
Explain  what  happens. 

18.  Create  a cl  ass  that  hasa  data  member  and  a derived  class 
that  adds  another  data  member.  Write  a non-member 
function  that  takes  an  object  of  the  base  cl  ass  by  i/a/ueand 
printsoutthesizeofthat  object  using  sizeof.  In  main( ) 
create  an  object  of  the  derived  class,  print  out  its  size,  and 
then  call  your  function.  Explain  what  happens. 

19.  Createasimpleexampleof  a virtual  function  call  and 
generate  assembly  output.  Locate  the  assembly  code  for 
the  virtual  call  and  trace  and  explain  the  code. 

20.  Write  a class  with  one  virtual  function  and  one  non- 
virtual function.  Inherit  a new  class,  make  an  object  of 
this  class,  and  upcast  to  a pointer  of  the  base-class  type. 
Usetheclock(  )function  found  in  <ctime>(you'll  need 
to  look  this  up  in  your  local  C library  guide)  to  measure 
the  difference  between  a virtual  call  and  non-virtual  call. 
You'll  need  to  make  multi  pie  cal  Is  to  each  function  inside 
yourtiming  loop  in  order  to  seethe  difference. 

21.  M od ify  C 14:0 rder.cppby  adding  a virtual  function  in 
the  baseclass  of  the  CLASS  macro  (have  it  print 
something)  and  by  making  the  destructor  virtual.  Make 
objects  of  the  various  subclasses  and  upcast  them  to  the 
baseclass.  Verify  that  the  virtual  behavior  works  and 
that  proper  construction  and  destruction  takes  place. 

22.  Write  a cl  ass  with  three  over  loaded  virtual  functions. 
Inherit  a new  class  from  thisand  override  one  of  the 
functions.  Create  an  object  of  your  derived  class.  Can  you 
call  all  the  base  cl  ass  functions  through  the  derived-class 
object?  U pcast  the  address  of  the  object  to  the  base.  Can 
you  call  all  three  functions  through  the  base?  Remove  the 
overridden  definition  in  thederived  class.  Now  can  you 
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call  all  the  base  cl  ass  functions  through  the  derived-class 
object? 

23.  M odify  VariantReturn.cpito  show  that  its  behavior 
works  with  references  as  well  as  pointers. 

24.  In  Early.cpp  how  can  you  tell  whether  the  compiler 
makes  the  cal  I using  early  or  I ate  binding?  Determine  the 
case  for  your  own  compiler. 

25.  Create  a baseclass  containing  a cl  one(  )function  that 
returns  a pointer  to  a copy  of  the  current  object.  Derive 
two  subclasses  that  override  cl one(  )to  return  copies  of 
their  specific  types.  In  main( ) create  and  upcast  objects 
of  your  two  derived  types,  then  call  clone(  )for  each  and 
verify  that  the  cloned  copies  are  the  correct  subtypes. 
Experiment  with  yourclone(  )function  so  that  you 
return  the  base  type,  then  try  returning  the  exact  derived 
type.  Can  you  think  of  situations  in  which  the  latter 
approach  is  necessary? 

26.  M odify  OStackT estxppby  creating  your  own  class,  then 
multiply-inheriting  it  with  Objectto  create  something 
that  can  be  placed  i nto  the  Stack.  T est  you r cl  ass  i n 

maln( ) 

27.  Add  atypecalled  Tensorto 

0 peratorPoly  morph  I sm  .cpp 

28.  (Intermediate)  Create  a baseclass  Xwith  no  data 
members  and  no  constructor,  but  with  a virtual  function. 
Create  a class  Ythat  inherits  from  X,  but  without  an 
explicit  constructor.  Generate  assembly  code  and 
examine  it  to  determine  if  a constructor  is  created  and 
called  for  X,  and  if  so,  what  the  code  does.  Explain  what 
you  discover.  X has  no  default  constructor,  so  why 
doesn't  the  compiler  complain? 

29.  (Intermediate)  Modify  Exercise28  by  writing 
constructors  for  both  classes  so  that  each  constructor  calls 
a virtual  function.  Generate  assembly  code.  Determine 
where  the  VPTR  is  being  assigned  inside  each 
constructor.  Is  the  virtual  mechanism  being  used  by  your 


720 


Thinking  in  C-I--I- 


www.BruceEckel.com 


compiler  inside  the  constructor?  Establish  why  thelocal 
versi  on  of  the  fu  ncti  on  i s sti  1 1 bei  ng  cal  I ed . 

30.  (Advanced)  If  function  cal  Is  to  an  object  passed  by  value 
weren't  early-bound,  a virtual  call  might  access  parts  that 
d i d n 't  exi  St.  I s th  i s possi  bl  e?  W r i te  some  cod  e to  force  a 
virtual  call,  and  seeif  this  causes  a crash.  To  explain  the 
behavior,  examine  what  happens  when  you  pass  an 
object  by  value. 

31.  (Advanced)  Find  out  exactly  how  much  moretime  is 
required  for  a virtual  function  call  by  going  to  your 
processor's  assembly-language  information  or  other 
technical  manual  and  finding  outthenumber  of  clock 
states  required  for  a simple  cal  I versus  the  number 
required  for  the  virtual  function  instructions. 

32.  DeterminethesizeoftheVPTR  for  your  implementation. 
Now  multiply-inherittwo  classes  that  contain  virtual 
functions.  Did  you  get  oneVPTR  or  two  in  thederived 
class? 

33.  Create  a class  with  data  members  and  virtual  functions. 
Write  a function  that  looks  at  the  memory  in  an  object  of 
your  class  and  prints  out  the  various  pieces  of  it.  To  do 
thisyou  will  need  to  experi ment  and  iteratively  discover 
where  the  VPTR  is  located  in  the  object. 

34.  Pretend  that  virtual  functions  don't  exist,  and  modify 

I nstrument4.cpp50  that  it  uses  dynamic_castto  make 
theequivalent  of  the  virtual  calls.  Explain  why  this  is  a 
bad  idea. 

35.  M odify  StaticH  ierarchyN avigation.cppo  that  instead  of 
using  C-H-RTTI  you  create  your  own  RTTI  via  a virtual 
function  in  the  base  cl  ass  cal  led  whatAml(  )and  an 
enum  type  {Circles,  Squares.]; 

36.  Start  with  PointeiToMemberOperator.cp^om  Chapter 
12  and  show  that  polymorphism  still  works  with 
pointers-to-members,  even  if  operator- >*is  overloaded. 
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16:  I ntroduction  to 
Templates 

Inheritance  and  composition  provide  a way  to  reuse 
object  code.  The  temp/ate  feature  in  C++  provides 
a way  to  reuse  source  code. 
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Although  C-H-templates  are  a general-purpose  programming  tool, 
when  they  were  introduced  in  the  language,  they  seemed  to 
discourage  the  use  of  object-based  container-class  hierarchies 
(demonstrated  at  the  end  of  Chapter  15).  For  example,  the  Standard 
C-H- containers  and  algorithms  (explained  in  two  chapters  of 
Volume  2 of  this  book,  down  load  able  from  www.BruceEckel.com}  are 
bui  It  exclusively  with  templates  and  are  relatively  easy  for  the 
programmer  to  use. 

This  chapter  not  only  demonstrates  the  basics  of  templates,  it  is  also 
an  introduction  to  containers,  which  are  fundamental  components 
of  object-oriented  programming  and  are  almost  completely  realized 
through  the  containers  in  the  Standard  C-H-Library.  You'll  see  that 
this  book  has  been  using  container  examples  - the  Stash  and  Stack 
- throughout,  precisely  to  get  you  comfortable  with  containers;  in 
thischaptertheconceptof  the/terator  will  also  be  added.  Although 
containers  are  ideal  examples  for  use  with  templates,  in  Volume2 
(which  has  an  advanced  templates  chapter)  you'll  learn  that  there 
are  many  other  uses  for  tempi  ates  as  wel  I . 


Containers 

Suppose  you  want  to  create  a stack,  as  we  have  been  doi  ng 
throughout  the  book.  Thisstack  class  will  hold  infe,to  keep  it 
simple: 

//:  Cl  6 : IntStack . cpp 
//  Simple  integer  stack 
//{L}  fibonacci 
#include  "fibonacci . h" 

#include  ".. /require . h" 

#include  <iostream> 
using  namespace  std; 

class  intStack  { 

enum  { ssize  = 100  }; 
int  stack [ssize] ; 
int  top; 
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Too  many  push()es"); 


public : 

IntStackO  : top(O)  {} 

void  push(int  i)  { 
require (top  < ssize, 
stack[top++]  = i; 

} 

int  popO  { 

require (top  > 0,  "Too  many  pop()s"); 
return  stack [ — top]; 


}; 


int  main  ( ) { 

IntStack  is; 

//  Add  some  Fibonacci  numbers,  for  interest: 
for(int  i = 0;  i < 20;  i++) 
is.push(fibonacci (i) ) ; 

//  Pop  & print  them: 
for(int  k = 0;  k < 20;  k++) 
cout  <<  is. pop  0 <<  endl; 

} ///:- 

The  class  I ntStackis  a trivial  exampleof  a push-down  stack.  For 
simplicity  it  has  been  created  herewith  a fixed  size,  but  you  can 
also  modify  it  to  automatically  expand  by  allocating  memory  off 
the  heap,  as  in  the  Stack  cl  ass  that  has  been  examined  throughout 
the  book. 

main( ) adds  some  integers  to  the  stack,  and  pops  them  off  again. 
T 0 make  the  exampi  e more  i nteresti  ng,  the  i ntegers  are  created 
with  thefibonacci(  function,  which  generates  the  traditional 
rabbit-reproduction  numbers.  Here  is  the  header  file  that  declares 
the  function: 

//:  C16 : f ibonacci . h 
//  Fibonacci  number  generator 
int  f ibonacci  (int  n) ; ///:- 

H ere's  the  i mpl  ementati  on : 

//:  C16 : f ibonacci . cpp  {0} 

#include  ".. /require . h" 
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int  f ibonacci (int  n)  { 
const  int  sz  = 100; 
require (n  < sz ) ; 

static  int  f[sz];  //  Initialized  to  zero 
f[0]  = f[l]  = 1; 

//  Scan  for  unfilled  array  elements: 
int  i ; 

for(i  = 0;  i < sz;  iff) 
if(f[i]  ==  0)  break; 
while  (i  <=  n)  { 

f[i]  = f[i-l]  + f[i-2]; 
i + + ; 

} 

return  f [n] ; 

} ///:- 

This  is  a fairiy  efficient  impiementati on,  because  it  never  generates 
the  numbers  more  than  once,  it  uses  a static  array  of  int  and  reiies 
on  the  fact  that  the  compi  i er  w i i i i niti  ai  i ze  a stati  carray  to  zero.  The 
f i rst  for  i oop  moves  the  i nd  ex  i to  w here  the  f i rst  array  ei  ement  i s 
zero,  then  a whiieioop  adds  Fibonacci  numbers  to  the  array  untii 
thedesired  dement  is  reached.  But  noticethat  if  the  Fibonacci 
numbers  through  dement  n areaiready  initiaiized,  it  skips  the 
whiieioop  ai  together. 

The  need  for  containers 

Obviousiy,  an  integer  stack  isn't  a crudai  tooi.  The  reai  need  for 
containers  comes  when  you  start  making  objects  on  the  heap  using 
new  and  destroying  them  with  deiete  inthegenerai  programming 
probiem,  you  don't  know  how  many  objects  you're  going  to  need 
whiieyou'rewriting  the  program.  For  exampie,  in  an  air-traffic 
controi  system  you  don't  want  to  i imit  the  number  of  pianes  your 
system  can  handie.  You  don't  want  the  program  to  abort  just 
because  you  exceed  some  number,  in  a computer-aided  design 
system,  you're  deaiing  with  iots  of  shapes,  but  oniy  the  user 
determines  (at  runtime)  exactiy  how  many  shapes  you're  going  to 
need.  Once  you  notice  this  tendency,  you'ii  discover  iots  of 
exampies  in  your  own  programming  situations. 
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C programmers  who  rely  on  virtual  memory  to  handle  their 
"memory  management"  often  find  the  idea  of  new,  delete, and 
container  classes  disturbing.  Apparently,  one  practice  in  C isto 
create  a huge  global  array,  larger  than  anything  the  program  would 
appear  to  need.  This  may  not  require  much  thought  (or  awareness 
of  malloc(  )and  free(  but  it  produces  programs  that  don't  port 
well  and  that  hide  subtle  bugs. 

In  addition,  if  you  createa  hugeglobal  array  of  objects  in  C++,  the 
constructor  and  destructor  overhead  can  slow  things  down 
significantly.  The  C++ approach  works  much  better:  When  you 
need  an  object,  create  it  with  new, and  put  its  pointer  in  a 
container.  Later  on,  fish  it  out  and  do  something  to  it.  This  way, 
you  create  only  the  objects  you  absolutely  need.  And  usually  you 
don't  haveall  the  initialization  conditions  avail  able  at  the  start-up 
of  the  program,  new  allows  you  to  wait  until  something  happens  in 
the  environment  before  you  can  actually  create  the  object. 

So  in  the  most  common  situation,  you'll  make  a contai  ner  that 
holds  pointers  to  some  objects  of  i nterest.  You  will  create  those 
objects  using  new  and  put  the  resulting  pointer  in  the  contai  ner 
(potentially  upcasting  it  in  the  process),  pulling  it  out  later  when 
you  want  to  do  someth!  ng  with  the  object.  This  technique  produces 
the  most  flexible,  general  sort  of  program. 


Overview  of  templates 

Now  a problem  arises.  You  have  an  IntStack  which  holds  integers. 
But  you  want  a stack  that  holds  shapes  or  aircraft  or  plants  or 
something  else.  Reinventing  your  source  code  every  time  doesn't 
seem  likea  very  intelligent  approach  with  a language  that  touts 
reusabi  I ity.  There  must  be  a better  way. 

There  are  three  techniques  for  source  code  reuse  in  this  situation: 
theC  way,  presented  here  for  contrast;  the  Smalltalk  approach, 
which  significantly  affected  C++,  and  the C-H- approach:  templates. 
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The  C solution  Of  course  you 're  trying  to  get  away  from  theC 
approach  because  it's  messy  and  error  prone  and  completely 
inelegant.  In  this  approach,  you  copy  the  source  code  for  a Stack 
and  make  modifications  by  hand,  introducing  new  errors  in  the 
process.  This  is  certainly  not  a very  productive  technique. 

The  Smalltalk  solutionSmalltalk  (and  Java,  following  its  example) 
took  a simple  and  straightforward  approach:  You  want  to  reuse 
code,  so  use  inheritance.  To  implement  this,  each  container  class 
hoi  ds  items  of  the  generi  c base  cl  ass  0 bject(si  mi  I ar  to  the  exampi  e 
at  the  end  of  Chapter  15).  But  because  the  library  in  Smalltalk  is  of 
such  fundamental  importance,  you  don't  ever  create  a cl  ass  from 
scratch.  Instead,  you  must  always  inherit  it  from  an  existing  class. 
You  find  a class  as  close  as  possible  to  the  one  you  want,  inherit 
from  it,  and  make  a few  changes.  Obviously,  this  is  a benefit 
becauseit  mini  mi  zes  your  effort  (and  explains  why  you  spend  a lot 
of  time  I earning  the  cl  ass  library  before  becoming  an  effective 
Smalltalk  programmer). 

But  it  also  means  that  all  classes  in  Smalltalk  end  up  being  part  of  a 
single  inheritance  tree.  You  must  inherit  from  a branch  of  this  tree 
when  creating  a new  class.  Mostof  the  tree  is  already  there  (it's  the 
Smal  Ital  k cl  ass  I i brary),  and  at  the  root  of  the  tree  i s a cl  ass  cal  I ed 
0 bject-  the  same  class  that  each  Smal  Ital  k contai  ner  holds. 

Thi  s i s a neat  tri  ck  because  it  means  that  every  cl  ass  i n the  Smal  Ital  k 
(and  J aval)  class  hierarchy  is  derived  from  Object  so  every  class 
can  beheld  in  every  container  (including  that  container  itself).  This 
type  of  single-tree  hierarchy  based  on  afundamental  generictype 
(often  named  Object  which  is  also  the  case  in  Java)  is  referred  to  as 
an  "object-based  hierarchy."  You  may  have  heard  this  term  and 
assumed  it  was  some  new  fundamental  concept  in  OOP,  like 
polymorphism.  It  simply  refersto  a class  hierarchy  with  Object(or 


1 With  the  exception,  inJava,  of  the  primitivedatatypes.  These  were  made  non- 
0 bj  ecfe  for  effi  ci  ency . 
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some  si  mi  I ar  name)  at  its  root  and  contai  ner  cl  asses  that  hoi  d 

Object 

Because  the  Smalltalk  cl  ass  library  had  a much  longer  history  and 
experience  behind  it  than  did  C++,  and  because  the  original  C++ 
compilers  had  no  contai  ner  cl  ass  libraries,  it  seemed  likeagood 
idea  to  duplicate  the  Smalltalk  library  in  C++.  This  was  done  as  an 
experiment  with  an  early  C++implementation2,  and  because  it 
represented  a significant  body  of  code,  many  people  began  using  it. 
In  the  process  of  trying  to  use  the  contai  ner  classes,  they  discovered 
a problem. 

The  problem  was  that  in  Small  talk  (and  most  other  OOP  languages 
that  I know  of),  all  cl  asses  are  automatically  derived  from  a single 
hierarchy,  but  this  isn't  true  in  C++.  You  might  have  your  nice 
object-based  hierarchy  with  its  contai  ner  classes,  but  then  you 
might  buy  a set  of  shape  classes  or  aircraft  classes  from  another 
vendor  who  didn't  use  that  hierarchy.  (For  one  thing,  using  that 
hierarchy  imposes  overhead,  which  C programmers  eschew.)  How 
do  you  i nsert  a separate  cl  ass  tree  i nto  the  contai  ner  cl  ass  i n your 
object-based  hierarchy?  Here's  what  the  problem  looks  like: 


Because  C-H- sup  ports  multiple  independent  hierarchies, 
Smalltalk's  object-based  hierarchy  does  not  work  so  well. 

The  solution  seemed  obvious.  If  you  can  have  many  inheritance 
hierarchies,  then  you  should  beableto  inherit  from  more  than  one 


2 The  00  PS  library,  by  Keith  Gorlen  while  he  was  at  N IH. 
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class:  Multiple  inheritance  will  solvetheproblenn.  So  you  clothe 
following  (a  similar  example  was  given  at  the  end  of  Chapter  15): 


Now  OShapehasShapefs  characteristics  and  behaviors,  but 
because  it  is  also  derived  from  Object  it  can  be  placed  in  Container 
The  extra  inheritance  into  OCircleO Square  etc.  is  necessary  so 
that  those  classes  can  be  upcast  into  0 Shapeand  thus  retain  the 
correct  behavior.  You  can  seethatthingsare  rapidly  getting  messy. 

Compiler  vendors  invented  and  included  their  own  object-based 
container-class  hierarchies,  most  of  which  have  since  been  replaced 
by  template  versions.  You  can  arguethat  multiple  inheritance  is 
needed  for  solving  general  programming  problems,  but  you'll  see 
in  Volume  2 of  this  book  that  its  complexity  is  best  avoided  except 
in  special  cases. 

The  template  solution 

Although  an  object-based  hierarchy  with  multiple  inheritance  is 
conceptually  straightforward,  it  turns  out  to  be  painful  to  use.  In 
his  original  book^Stroustrup  demonstrated  what  he  considered  a 
preferable  alternativeto  the  object-based  hierarchy.  Container 
classes  were  created  as  large  preprocessor  macros  with  arguments 
that  could  be  substituted  with  your  desired  type.  When  you 


^ The  C++  Programming  Languageby  BjarneStroustrup  (1st  edition,  Addison-Wesley, 
1986). 
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wanted  to  create  a container  to  hold  a particular  type,  you  made  a 
couple  of  macro  calls. 

Unfortunately,  thisapproach  was  confused  by  all  the  existing 
Smalltalk  literature  and  programming  experience,  and  it  wasa  bit 
unwieldy.  Basically,  nobody  got  it. 

In  the  meantime,  Stroustrup  and  the  C-H- team  at  Bell  Labs  had 
modified  his  original  macro  approach,  simplifying  it  and  moving  it 
from  the  domai  n of  the  preprocessor  i nto  the  compi  I er.  Thi s new 
code-substitution  device  is  cal  led  a template,  and  it  represents  a 
completely  different  way  to  reuse  code.  I nstead  of  reusing  object 
code,  aswith  inheritance  and  composition,  a tempi  ate  reuses  sot;  rce 
code.  The  container  no  longer  holds  a generic  base  class  called 
Object  but  instead  it  holds  an  unspecified  parameter.  When  you 
use  a template,  the  parameter  is  substituted  by  the  compiler,  much 
I ike  the  old  macro  approach,  but  cleaner  and  easier  to  use. 

Now,  instead  of  worrying  about  inheritance  or  composition  when 
you  want  to  use  a contai  ner  cl  ass,  you  take  the  tempi  ate  versi  on  of 
the  container  and  stamp  out  a specific  version  for  your  particular 
problem,  I ike  this: 


The  compiler  does  the  work  for  you,  and  you  end  up  with  exactly 
the  contai  ner  you  need  to  do  your  job,  rather  than  an  unwieldy 
inheritance  hierarchy.  In  C-H-,  the  tempi  ate  implements  the  concept 
of  a parameterized  type.  A nother  benefit  of  the  tempi  ate  approach  i s 
that  the  novice  programmer  who  may  beunfamiliar  or 


^ The  i nspi  rati  on  for  tempi  ates  appears  to  be  A DA  generi  cs. 
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uncomfortable  with  inheritance  can  still  use  canned  container 
classes  right  away  (as  we've  been  doing  with  vectorthroughout  the 
book). 


Template  syntax 

The  tempi  atekeyword  tel  Is  the  compiler  that  the  class  defi  nition 
that  follows  will  manipulate  one  or  more  unspecified  types.  Atthe 
timetheactual  class  code  is  generated  from  the  template,  those 
types  must  be  specified  so  that  the  compi  ler  can  substitute  them. 

To  demonstrate  the  syntax,  here's  a small  example  that  produces  a 
bounds-checked  array: 

//:  Cl  6 : Array . cpp 
#include  ".. /require . h" 

#include  <iostream> 
using  namespace  std; 

template<class  T> 
class  Array  { 

enum  { size  = 100  } ; 

T A [ size ] ; 
public : 

T&  operator [] (int  index)  { 

require ( index  >=  0 &&  index  < size, 

"index  out  of  range"); 
return  A[index]; 


}; 


int  main  ( ) { 

Array<int>  ia; 

Array<float>  fa; 
for(int  i = 0;  i < 20;  itt)  { 
ia [i]  = i * i; 
fa [i]  = float  (i)  * 1 .414; 

} 

for(int  j = 0;  j < 20;  j++) 

cout  <<  j <<  " <<  ia[j] 

<<  ",  " <<  fa[j]  <<  endl; 
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} III-.- 


You  can  see  that  it  looks  I ike  a normal  cl  ass  except  for  the  line 

template<class  T> 

which  saysthatT  is  the  substitution  parameter,  and  that  it 
represents  a type  name.  Also,  you  seeT  used  everywhere  in  the 
class  where  you  would  normally  seethe  specifictypethecontainer 
holds. 

In  Array,  elements  are  inserted  and  extracted  with  the  same 
function:  the  overloaded  operator  [ J It  returns  a reference,  so  it 
can  be  used  on  both  sides  of  an  equal  sign  (that  is,  as  both  an  lvalue 
and  an  rvalue).  Noticethatiftheindexisoutof  bounds,  the 
require(  Kunction  is  used  to  print  a message.  Sinceoperator[]is  an 
inline  you  could  use  this  approach  to  guarantee  that  no  array- 
bounds  violations  occur,  then  remove  the  require!  Korthe 
shipping  code. 

In  main! ) you  can  see  how  easy  it  isto  create  Arrays  that  hold 
different  types  of  objects.  When  you  say 

Array<int>  ia; 

Array<float>  fa; 

the  compiler  expands  the  Array  template  (this  is  cal  led 
Instantiation)  twice,  to  create  two  new  generated  classes,  which  you 
can  th  i n k of  as  A rray_  i ntan  d A rray_f  I oat  ( D i fferent  comp  i I ers 
may  decorate  the  names  in  different  ways.)  These  are  classes  just 
I i ke  the  ones  you  would  have  produced  if  you  had  performed  the 
substitution  by  hand,  except  that  the  compiler  creates  them  for  you 
as  you  define  the  objects  ia  and  fa.  Also  note  that  duplicate  class 
definitions  are  either  avoided  by  the  compiler  or  merged  by  the 
linker. 
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Non-inline  function  definitions 

Of  course,  there  are  times  when  you'll  want  to  have  non-inline 
member  function  definitions.  In  thiscase,  the  compiler  needs  to  see 
thetemplatedeclaration  before  the  member  function  definition. 
Here's  the  example  above,  modified  to  show  the  non-inline 
member  definition: 

//:  Cl  6 : Array2 . cpp 

//  Non-inline  template  definition 

#include  ".. /require . h" 

template<class  T> 
class  Array  { 

enum  { size  = 100  } ; 

T A [ size ] ; 
public : 

T&  operator  []  (int  index); 

}; 


template<class  T> 

T&  Array<T> :: operator [ ] (int  index)  { 
require ( index  >=  0 &&  index  < size, 

"index  out  of  range"); 
return  A[index]; 

} 

int  main  ( ) { 

Array<float>  fa; 
fa[0]  = 1.414; 

} ///:- 

Any  reference  to  a template's  class  name  must  be  accompanied  by 
its  tempi  ate  argument  list,  as  in  Array<T>::operator[Jfou  can 
imagine  that  internally,  the  class  nameis  being  decorated  with  the 
arguments  in  the  tempi  ate  argument  I ist  to  produce  a unique  class 
name  identifier  for  each  template  instantiation. 

Header  files 

Even  if  you  create  non-inlinefunction  definitions,  you'll  usually 
want  to  put  all  declarations  and  definitions  for  a template  into  a 
header  file.  This  may  seem  to  viol  ate  the  normal  header  file  rule  of 
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"Don't  put  in  anything  that  allocates  storage,"  (which  prevents 
multipledefinition  errors  at  link  time),  but  tempi  ate  definitions  are 
special.  Anything  preceded  by  template<...>means  the  compiler 
won't  allocate  storage  for  it  at  that  point,  but  will  instead  wait  until 
it's  told  to  (by  a template  instantiation),  and  that  somewhere  in  the 
compiler  and  linker  there's  a mechanism  for  removing  multiple 
definitions  of  an  identical  template.  So  you 'I  I almost  always  put  the 
entire  tempi  ate  declaration  and  definition  in  the  header  file,  for  ease 
of  use. 

There  are  times  when  you  may  need  to  pi  ace  the  tempi  ate 
definitions  in  a separatecppfileto  satisfy  special  needs  (for 
example,  forcing  template  instantiations  to  exist  in  only  a single 
W i ndows  dl  I f i I e).  M ost  compi  I ers  have  some  mechani  sm  to  al  I ow 
this;  you'll  have  to  invest!  gate  your  particular  compiler's 
documentation  to  use  it. 

Some  people  feel  that  putting  all  of  the  source  code  for  your 
implementation  in  a header  file  makes  it  possiblefor  peopleto  steal 
and  modify  your  code  if  they  buy  a library  from  you.  This  might  be 
an  issue,  but  it  probably  depends  on  the  way  you  look  at  the 
problem:  Are  they  buying  a product  or  a service?  If  it's  a product, 
then  you  have  to  do  everything  you  can  to  protect  it,  and  probably 
you  don't  want  to  give  source  code,  just  compi  led  code.  But  many 
people  see  software  as  a service,  and  even  more  than  that,  a 
subscription  service.  The  customer  wants  your  expertise,  they  want 
you  to  conti  nue  mai  ntai ni  ng  thi s piece  of  reusabi e code  so  that  they 
don't  have  to  - so  they  can  focus  on  getting  the  r job  done.  I 
personally  think  most  customers  will  treat  you  as  a valuable 
resource  and  will  not  want  to  jeopardizetheir  relationship  with 
you.  As  for  the  few  who  want  to  steal  rather  than  buy  or  do  original 
work,  they  probably  can't  keep  up  with  you  anyway. 

I ntStack  as  a template 

H ere  i s the  contai ner  and  iterator  from  I ntStackxpp  i mpl emented 
as  a generi  c contai  ner  cl  ass  usi  ng  tempi  ates: 
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//:  Cl  6 : StackTemplate . h 
//  Simple  stack  template 
#ifndef  STACKTEMPLATE_H 
#define  STACKTEMPLATE_H 
#include  /require . h" 

template<class  T> 
class  StackTemplate  { 
enum  { ssize  = 100  }; 

T stack [ssize] ; 
int  top; 
public : 

StackTemplate ( ) : top(O)  {} 

void  push (const  T&  i)  { 

require (top  < ssize,  "Too  many  push()es"); 
stack[top++]  = i; 

} 

T popO  { 

require (top  > 0,  "Too  many  pop()s"); 
return  stack [ — top]; 

} 

int  sizeO  { return  top;  } 

}; 

#endif  //  STACKTEMPLATE_H  ///:- 

N otice  that  a template  makes  certai  n assumptions  about  the  objects 
it  is  holding.  For  example,  StackTemplateassumes  there  is  some 
sortof  assignment  operation  for  T insidethepush(  )function.  You 
could  say  that  a template  "implies  an  interface"  for  the  types  it  is 
capable  of  holding. 

Another  way  to  say  this  is  that  templates  provide  a kind  of  weak 
typing  mechanism  for  C++,  which  is  ordinarily  a strongly-typed 
language.  Instead  of  insisting  that  an  object  be  of  some  exact  type  in 
order  to  be  acceptable,  weak  typing  requires  only  that  the  member 
functions  that  it  wants  to  call  are  avail  able  for  a particular  object. 
Thus,  weakly-typed  code  can  be  applied  to  any  object  that  can 
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accept  those  member  function  calls,  and  is  thus  much  more 
flex!  ble^. 


Here's  the  revised  example  to  test  the  tempi  ate: 

//:  Cl  6 : StackTemplateTest . cpp 
//  Test  simple  stack  template 
//{L}  fibonacci 
#include  "fibonacci . h" 

#include  "StackTemplate . h" 

#include  <iostream> 

#include  <fstream> 

#include  <string> 
using  namespace  std; 

int  main  ( ) { 

StackTemplate<int>  is; 
for(int  i = 0;  i < 20;  it+) 
is.push(fibonacci  (i) ) ; 
for(int  k = 0;  k < 20;  k++) 
cout  <<  is. pop  0 <<  endl; 
if stream  in ( "StackTemplateTest . cpp" ) ; 
assure  (in,  "StackTemplateTest . cpp" ) ; 
string  line; 

StackTemplate<string>  strings; 
while (getline (in,  line)) 
strings . push ( line ) ; 
while (strings . size  ( ) > 0) 

cout  <<  strings . pop ( ) <<  endl; 

} ///:- 

The  only  difference  is  in  the  creation  of  is.  Inside  the  tempi  ate 
argument  list  you  specify  the  type  of  object  the  stack  and  iterator 
should  hold.  To  demonstrate  the  genericness  of  the  template,  a 
StackTemplateis  also  created  to  hold  string  This  is  tested  by 
reading  in  lines  from  the  source-code  file. 


^All  methods  in  both  Smalltalk  and  Python  areweakly  typed,  and  so  those 
languages  do  not  need  a template  mechanism.  In  effect,  you  get  templates  without 
templates. 
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Constants  in  templates 

Template  arguments  are  not  restricted  to  cl  ass  types;  you  can  also 
use  bui  It-i  n types.  The  values  of  these  arguments  then  become 
compile-time  constants  for  that  particular  instantiation  of  the 
template.  You  can  even  use  default  values  for  these  arguments.  The 
following  example  allows  you  to  set  the  size  of  the  Array  class 
during  instantiation,  but  also  provides  a default  value: 

//:  Cl  6 : Arrays . cpp 

//  Built-in  types  as  template  arguments 
#include  ".. /require . h" 

#include  <iostream> 
using  namespace  std; 

template<class  T,  int  size  = 100> 
class  Array  { 

T array [size]  ; 
public : 

T&  operator [] (int  index)  { 

require ( index  >=  0 &&  index  < size, 

"Index  out  of  range"); 
return  array [ index] ; 

} 

int  length])  const  { return  size;  } 

}; 


class  Number  { 
float  f; 
public : 

Number (float  ff  = O.Of)  : f(ff)  {} 

Numbers  operator=  (const  Numbers  n)  { 
f = n . f ; 
return  *this; 

} 

operator  float])  const  { return  f;  } 
friend  ostreamS 

operator<< (ostreamS  os,  const  Numbers  x)  { 
return  os  <<  x.f; 


}; 


template<class  T,  int  size  = 20> 
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class  Holder  { 

Array<T,  size>*  np; 
public : 

Holder  0 : np ( 0 ) { } 

T&  operator[]  (int  1)  { 

require (0  <=!&&!<  size); 
if(!np)  np  = new  Array<T,  size>; 
return  np->operator  [ ] (1); 

} 

int  length  0 const  { return  size;  } 
-Holder  0 { delete  np;  } 

}; 

int  main  ( ) { 

Holder<Number>  h; 


for ( Int  1 

= 0; 

i 

< 20; 

1++) 

h[l]  = 

i; 

for ( Int  j 

= 0; 

j 

< 20; 

j++) 

cout  << 

h[  j] 

<< 

endl ; 

} ///:- 

A s before,  A rray  i s a checked  array  of  objects  and  prevents  you 
from  indexing  out  of  bounds.  The  class  Holder  is  much  I ike  A rray 
except  that  it  has  a poi  nter  to  an  A rray  i nstead  of  an  embedded 
object  of  type  Array.  This  pointer  is  not  initialized  in  the 
constructor;  the  initialization  is  delayed  until  the  first  access.  This  is 
called  lazy  initialization;  you  might  useatechniquelikethis  if  you 
are  creating  a lot  of  objects,  but  not  accessing  them  all,  and  want  to 
save  storage. 

You'll  notice  that  the  sizevalue  in  both  templates  is  never  stored 
internally  in  the  class,  but  it  is  used  as  if  it  were  a data  member 
i nsi  de  the  member  f u ncti  ons. 


stack  and  Stash 
as  templates 

The  recurring  "ownership"  problems  with  the  Stash  and  Stack 
container  classes  that  have  been  revisited  throughout  this  book 
come  from  the  fact  that  these  contai  ners  haven't  been  abl  e to  know 
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exactly  what  types  they  hold.  The  nearest  they've  come  is  the  Stack 
"container  of  Object  that  was  seen  at  the  end  of  Chapter  15  in 

OStackTestxpp 

If  the  client  programmer  doesn't  explicitly  remove  all  the  pointers 
to  objects  that  are  hel  d I n the  cental  ner,  then  the  cental  ner  shou  I d 
be  ableto  correctly  delete  those  pointers.  That  isto  say,  the 
container  "owns"  any  objects  that  haven't  been  removed,  and  is 
thus  responsible  for  cleaning  them  up.  The  snag  has  been  that 
cleanup  requires  knowing  the  type  of  the  object,  and  creating  a 
generi  c cental  ner  cl  ass  requ  I res  not  know!  ng  the  type  of  the  object. 
With  templates,  however,  we  can  write  codethat  doesn't  know  the 
type  of  the  object,  and  easily  instant!  ate  a new  version  of  that 
container  for  every  type  that  we  want  to  contain.  The  individual 
i nstanti  ated  contai  ners  do  know  the  type  of  objects  they  hoi  d and 
can  thus  cal  I the  correct  destructor  (assuming,  in  the  typical  case 
where  polymorphism  is  involved,  that  a virtual  destructor  has  been 
provided). 

For  the  Stack  this  turns  out  to  be  quite  si  mple  since  al  I of  the 
member  functions  can  be  reasonably  inlined: 

//:  C16:TStack.h 
//  The  Stack  as  a template 
#ifndef  TSTACK_H 
#define  TSTACK_H 

template<class  T> 
class  Stack  { 
struct  Link  { 

T*  data; 

Link*  next; 

Link(T*  dat.  Link*  nxt) : 
data(dat),  next  (nxt)  {} 

}*  head; 
public : 

Stack ( ) : head ( 0 ) { } 

-Stack ( ) { 

while (head) 
delete  pop  ( ) ; 
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} 

void  push(T*  dat)  { 

head  = new  Link (dat,  head); 

} 

T*  peek  ( ) const  { 

return  head  ? head->data  : 0; 

} 

T*  pop  ( ) { 

if (head  ==  0)  return  0; 

T*  result  = head->data; 

Link*  oldHead  = head; 
head  = head->next; 
delete  oldHead; 
return  result; 


}; 

#endif  //  TSTACK_H  ///:- 

If  you  comparethistotheOStack.hexampleattheerKd  of  Chapter 
15,  you  will  see  that  Stackis  virtually  irdentical,  except  that  Object 
has  been  replaced  with  T.  The  test  program  is  also  nearly  identical, 
except  that  the  necessity  for  multiply-inheriting  from  stringand 
Object(and  even  the  need  for  Objectitself)  has  been  eliminated. 
Now  thereisno  MyStringclassto  announce  its  destruction,  so  a 
small  new  class  is  added  to  show  a Stack  container  cleaning  up  its 
objects: 

//:  Cl  6 : TStackTest . cpp 
//{T}  TStackTest . cpp 
#include  "TStack.h" 

#include  /require . h" 

#include  <fstream> 

#include  <iostreain> 

#include  <string> 
using  namespace  std; 

class  X { 
public : 

virtual  ~X ( ) { cout  <<  "~X  " <<  endl;  } 

}; 


int  main(int  argc,  char*  argv [ ] ) { 

requireArgs (argc,  1);  //  File  name  is  argument 
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ifstream  in(argv[l]); 
assure (in,  argv[l]); 

Stack<string>  textlines; 
string  line; 

//  Read  file  and  store  lines  in  the  Stack: 
while (getline  (in,  line)) 

textlines . push (new  string (line) ) ; 

//  Pop  some  lines  from  the  stack: 
string*  s; 

for(int  i = 0;  i < 10;  iff)  { 

if ( (s  = ( string* ) text lines . pop  0) ==0 ) break; 
cout  <<  *s  <<  endl; 
delete  s; 

} //  The  destructor  deletes  the  other  strings. 

//  Show  that  correct  destruction  happens: 

Stack<X>  xx; 

for(int  j = 0;  j < 10;  j++) 

XX . push (new  X) ; 

} ///:- 

The  (destructor  for  X is  virtual,  not  because  it's  necessary  here,  but 
because XX  could  later  be  used  to  hold  objects  derived  fromX. 

Notice  how  easy  it  isto  create  different  kindsof  Stacks  for  string 
and  for  X.  Because  of  thetennplate,  you  get  the  best  of  both  worlds: 
the  ease  of  use  of  the  Stack  cl  ass  along  with  proper  cleanup. 

Templatized  pointer  Stash 

Reorganizi  ng  the  PStash  code  i nto  a tennpl ate  isn't  quite  so  si  mple 
becausethere  are  a number  of  member  functions  that  should  not  be 
inlined.  However,  as  a tempi  ate  those  function  definitions  still 
bel  ong  i n the  header  fi  I e (the  compi  I er  and  I i nker  take  care  of  any 
multi  pie  defi  nition  problems).  The  code  looks  quite  si  mi  lar  to  the 
ordinary  PStash  except  that  you'll  noticethesizeof  the  increment 
(used  by  inflate( ) has  been  templatized  as  a non-class  parameter 
with  a default  value,  so  that  the  increment  size  can  be  modified  at 
the  poi nt  of  i nstanti ati on  (noti ce  that  this  means  that  the  i ncrement 
size  is  fixed;  you  may  also  argue  that  the  increment  size  should  be 
changeabi  e throughout  the  I ifeti  me  of  the  object) : 
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//:  C16:TPStash.h 
#ifndef  TPSTASH_H 
#define  TPSTASH_H 

template<class  T,  int  incr  = 10> 
class  PStash  { 

int  quantity;  //  Number  of  storage  spaces 
int  next;  //  Next  empty  space 
T**  storage; 

void  inflate (int  increase  = incr); 
public : 

PStashO  : quantity  (0),  next(O),  storage  (0)  {} 

-PStash  ( ) ; 

int  add(T*  element); 

T*  operator []  (int  index)  const;  //  Fetch 
//  Remove  the  reference  from  this  PStash: 

T*  remove (int  index); 

//  Number  of  elements  in  Stash: 
int  count  0 const  { return  next;  } 


template<class  T,  int  incr> 
int  PStash<T,  incr> : : add (T*  element)  { 
if  (next  >=  quantity) 
inflate (incr) ; 
storage [next+t]  = element; 
return (next  - 1);  //  Index  number 

} 

/ / Ownership  of  remaining  pointers : 
template<class  T,  int  incr> 

PStash<T,  incr> :: -PStash ( ) { 

for  (int  i = 0;  i < next;  i++)  { 

delete  storage [i];  //  Null  pointers  OK 
storage [i]  = 0;  //  Just  to  be  safe 

} 

delete  [] storage; 

} 

template<class  T,  int  incr> 

T*  PStash<T,  incr> :: operator [ ] (int  index)  const  { 
require ( index  >=  0, 

"PStash :: operator [ ] index  negative"); 
if (index  >=  next) 

return  0;  //  To  indicate  the  end 
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require (storage [index]  !=  0, 

"PStash :: operator  [ ] returned  null  pointer"); 

//  Produce  pointer  to  desired  element: 
return  storage [ index] ; 

} 

template<class  T,  int  incr> 

T*  PStash<T,  incr> :: remove ( int  index)  { 

//  operator []  performs  validity  checks: 

T*  V = operator [] (index); 

//  "Remove"  the  pointer: 

if (v  !=  0)  storage [ index]  = 0; 

return  v; 

} 

template<class  T,  int  incr> 

void  PStash<T,  incr> :: inf late  ( int  increase)  { 
const  int  psz  = sizeof(T*); 

T**  St  = new  T* [quantity  + increase]; 

memset (st,  0,  (quantity  + increase)  * psz); 

memcpy(st,  storage,  quantity  * psz); 

quantity  +=  increase; 

delete  [] storage;  //  Old  storage 

storage  = st;  //  Point  to  new  memory 

} 

#endif  //  TPSTASH_H  ///:- 

The  (default  increment  size  used  hereissmall  to  guarantee  that  calls 
toinflate(  )occur.  Thisway  wecan  make  sure  it  works  correctly. 

To  test  the  ownership  control  of  the  tempi  ati  zed  PStash,  the 
following  classwill  report  creations  and  destructions  of  itself,  and 
also  guarantee  that  all  objects  that  have  been  created  were  also 
destroyed.  AutoCounterwill  allow  only  objects  of  its  type  to  be 
created  on  the  stack: 

//:  Cl  6 : AutoCounter . h 
#ifndef  AUTOCOUNTER_H 
#define  AUTOCOUNTER_H 
#include  ".. /require . h" 

#include  <iostream> 

#include  <set>  //  Standard  C++  Library  container 
#include  <string> 
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class  AutoCounter  { 
static  int  count; 
int  id; 

class  CleanupCheck  { 

std : : set<AutoCounter*>  trace; 
public : 

void  add (AutoCounter*  ap)  { 
trace . insert (ap)  ; 

} 

void  remove (AutoCounter*  ap)  { 
require (trace . erase (ap)  ==  1, 

"Attempt  to  delete  AutoCounter  twice"); 

} 

-CleanupCheck ( ) { 

std::cout  <<  "-CleanupCheck () "<<  std::endl; 
require (trace . size ( ) ==  0, 

"All  AutoCounter  objects  not  cleaned  up"); 

} 

}; 

static  CleanupCheck  verifier; 

AutoCounter ( ) : id(count++)  { 

verifier . add (this ) ; //  Register  itself 

std::cout  <<  "created["  <<  id  <<  "]" 

<<  std : : endl ; 

} 

//  Prevent  assignment  and  copy-construction: 
AutoCounter (const  AutoCounter& ) ; 
void  operator= (const  AutoCounter& ) ; 
public : 

//  You  can  only  create  objects  with  this: 
static  AutoCounter*  create  ()  { 

return  new  AutoCounter  () ; 

} 

-AutoCounter ( ) { 

std::cout  <<  "destroying [ " <<  id 
<<  "]"  <<  std::endl; 
verifier . remove (this ) ; 

} 

//  Print  both  objects  and  pointers: 
friend  std : : ostream&  operator<<  ( 

std : : ostream&  os,  const  AutoCounter&  ac) { 
return  os  <<  "AutoCounter  " <<  ac.id; 

} 

friend  std : : ostream&  operator<<  ( 
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std : : ostream&  os,  const  AutoCounter*  ac) { 
return  os  <<  "AutoCounter  " <<  ac->id; 


}; 

#endif  //  AUTOCOUNTER_H  ///:- 

TheAutoCounterdassdoes two  things.  First,  it  sequent! aiiy 
numbers  each  instance  of  AutoCounterthevaiueofthisnumber  is 
kept  in  id,  and  the  number  is  generated  using  the staticdata 
member  count 

Second,  and  morecompiex,  astaticinstance(caiied  verified  of  the 
nested  dass  CleanupCheckkeeps  track  of  aii  of  the  AutoCounter 
objects  that  are  created  and  destroyed,  and  reports  back  to  you  if 
you  don't  dean  aii  of  them  up  (i.e.  if  there  is  a memory  ieak).This 
behavior  isaccompiished  using  a set  dass  from  the  Standard  C++ 
Library,  which  isa  wonderfui  exampieof  how  weii-designed 
tempiatescan  make  iife  easy  (you  can  iearn  about  aii  the  containers 
i n the  Stand ard  C ++  L i brary  i n Voi  u me  2 of  thi s book,  avai  i abi  e 
oniine). 

Thesetciass  istempiatized  on  the  type  that  it  hoids;  here  it  is 
instantiated  to  hoi d A utoCounterpointers.  A setwiii  aiiowoniy 
one  instance  of  each  distinct  object  to  be  added;  in  add(  )you  can 
see  thi  stake  pi  ace  with  theset::insert(  )function.  insert(  )actuaiiy 
informs  you  with  its  return  vaiue  if  you're  trying  to  add  something 
that's  ai  ready  been  added;  however,  si  nee  object  addresses  are 
being  added  we  can  reiy  on  C++'s  guarantee  that  aii  objects  have 
unique  addresses. 

in  remove( ) set::erase(  )s  used  to  remove  an  AutoCounter 

pointer  from  the  set  The  return  vaiueteiisyou  how  many  instances 
of  the  dement  were  removed;  in  our  caseweoniy  expect  zero  or 
one.  if  the  vaiue  is  zero,  however,  it  means  this  object  was  ai  ready 
deieted  from  the  set  and  you'retryingtodeieteitasecond  time, 
which  isa  programming  error  that  wiii  be  reported  through 
require( ) 
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The  destructor  for  CleanupCheckdoes  a final  check  by  making 
su  re  that  the  size  of  the  set  i s zero  -this  means  that  al  I of  the  objects 
have  been  properly  cleaned  up.  If  it's  not  zero,  you  have  a memory 
leak,  which  is  reported  through  require( ) 

The  constructor  and  destructor  for  AutoCounterregister  and 
unregister  themselves  with  theverifierobject.  Notice  that  the 
constructor,  copy-constructor,  and  assignment  operator  are  private 
so  the  only  way  for  you  to  create  an  object  is  with  the  static  create( ) 
member  function  - this  isasimpleexampleof  a factory,  and  it 
guarantees  that  all  objects  are  created  on  the  heap,  so  verifierwill 
not  get  confused  over  assignments  and  copy-constructions. 

Since  all  of  the  member  functions  have  been  inlined,  the  only 
reason  for  the  implementation  file  is  to  contain  the  static  data 
member  definitions: 

//:  Cl  6 : AutoCounter . cpp  {0} 

//  Definition  of  static  class  members 
#include  "AutoCounter . h" 

AutoCounter: : CleanupCheck  AutoCounter: :verifier; 
int  AutoCounter :: count  = 0; 

///:- 

With  AutoCounteiin  hand,  wecan  now  test  the  facilities  of  the 
PStash  The  following  example  not  only  shows  that  the  PStash 
destructor  cleans  up  all  the  objects  that  it  currently  owns,  but  it  also 
demonstrates  how  the  A utoCountercl  ass  detects  objects  that 
haven't  been  cleaned  up: 

//:  Cl  6 : TPStashTest . cpp 
//{L}  AutoCounter 
#include  "AutoCounter . h" 

#include  "TPStash.h" 

#include  <iostream> 

#include  <fstream> 
using  namespace  std; 

int  main  ( ) { 

PStash<AutoCounter>  acStash; 
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for(int  i = 0;  i < 10;  i++) 

acStash . add (AutoCounter : : create ( ) ) ; 
cout  <<  "Removing  5 manually:"  <<  endl; 
for(int  j = 0;  j < 5;  j++) 
delete  acStash . remove ( j ) ; 
cout  <<  "Remove  two  without  deleting  them:" 

<<  endl; 

//  ...  to  generate  the  cleanup  error  message. 

cout  <<  acStash . remove ( 5 ) <<  endl; 

cout  <<  acStash . remove ( 6 ) <<  endl; 

cout  <<  "The  destructor  cleans  up  the  rest:" 

<<  endl; 

//  Repeat  the  test  from  earlier  chapters: 
if stream  in ("TPStashTest . cpp" ) ; 
assure  (in,  "TPStashTest . cpp" ) ; 

PStash<string>  stringStash; 
string  line; 

while (getline (in,  line)) 

stringStash . add (new  string(line) ) ; 

//  Print  out  the  strings: 

for(int  u = 0;  stringStash [u] ; u++) 

cout  <<  " stringStash [ " <<  u <<  "]  = " 

<<  *stringStash [u]  <<  endl; 

} ///:- 

When  AutoCounterelements5an(d  6 are  removed  from  the 
PStash,  they  become  the  responsibility  of  the  caller,  but  si  nee  the 
caller  never  cleansthem  up  they  cause  memory  leaks,  which  are 
then  detected  by  AutoCountei^t  run  time. 

When  you  run  the  program,  you'll  see  that  the  error  message  isn't 
as  specific  as  it  could  be.  If  you  use  the  scheme  presented  in 
AutoCounterto  discover  memory  leaks  in  your  own  system,  you 
will  probably  want  to  have  it  printout  moredetailed  information 
about  the  objects  that  haven't  been  cleaned  up.  Volume  2 of  this 
book  shows  more  sophisticated  ways  to  do  this. 


Turning  ownership  on  and  off 

Let's  return  to  the  ownership  problem.  Containers  that  hold  objects 
by  value  don't  usually  worry  about  ownership  because  they  clearly 
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own  the  objects  they  contain.  But  if  your  container  holds  pointers 
(which  is  more  common  with  C++,  especially  with  polymorphism), 
then  it's  very  likely  those  pointers  may  also  be  used  somewhere 
else  in  the  program,  and  you  don't  necessarily  want  to  delete  the 
object  because  then  the  other  pointers  in  the  program  would  be 
referencing  a destroyed  object.  To  prevent  this  from  happening, 
you  must  consider  ownership  when  designing  and  using  a 
contai  ner. 

Many  programs  are  much  simpler  than  this,  and  don't  encounter 
the  ownership  problem:  One  container  holds  pointers  to  objects 
that  are  used  only  by  that  contai  ner.  In  this  case  ownership  isvery 
straightforward:  The  container  owns  its  objects. 

The  best  approach  to  handling  the  ownership  problem  isto  give  the 
client  programmer  a choice.  This  is  often  accomplished  by  a 
constructor  argument  that  defaults  to  indicating  ownership  (the 
simplest  case).  In  addition  there  may  be  "get"  and  "set"  functions 
to  view  and  modify  the  ownership  of  the  contai  ner.  If  the  contai  ner 
has  functions  to  removean  object,  the  ownership  state  usually 
affects  that  removal,  so  you  may  also  find  options  to  control 
destruction  in  the  removal  function.  You  could  conceivably  add 
ownership  data  for  every  element  in  the  contai  ner,  so  each  position 
would  know  whether  it  needed  to  be  destroyed;  this  isa  variant  of 
reference  counting,  except  that  the  contai  ner  and  not  the  object 
knows  the  number  of  references  pointing  to  an  object. 

//:  Cl  6 : OwnerStack . h 

//  Stack  with  runtime  conrollable  ownership 
#ifndef  OWNERS TACK_H 
#define  OWNERSTACK_H 

template<class  T>  class  Stack  { 
struct  Link  { 

T*  data; 

Link*  next; 

Link(T*  dat.  Link*  nxt) 

: data (dat),  next  (nxt)  {} 

}*  head; 
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bool  own; 
public : 

Stack  (bool  own  = true)  : head(O),  own (own)  {} 
-Stack ( ) ; 

void  push(T*  dat)  { 

head  = new  Link (dat , head) ; 

} 

T*  peek  ( ) const  { 

return  head  ? head->data  : 0; 

} 

T*  pop  ( ) ; 

bool  ownsO  const  { return  own;  } 
void  owns (bool  newownership)  { 
own  = newownership; 

} 

//  Auto-type  conversion:  true  if  not  empty: 
operator  bool()  const  { return  head  !=  0;  } 


template<class  T>  T*  Stack<T> : : pop ( ) { 

if (head  ==  0)  return  0; 

T*  result  = head->data; 

Link*  oldHead  = head; 
head  = head->next; 
delete  oldHead; 
return  result; 

} 

template<class  T>  Stack<T> :: -Stack ( ) { 

if(!own)  return; 
while (head) 
delete  pop ( ) ; 

} 

#endif  //  OWNERSTACK_H  ///:- 

The  default  behavior  is  for  the  container  to  destroy  its  objects  but 
you  can  change  this  by  either  modifying  the  constructor  argument 
or  using  theowns(  )read/  write  member  functions. 

As  with  most  templates  you're  likely  to  see,  the  entire 
implementation  is  contained  in  the  header  file.  Here's  a small  test 
that  exercises  the  ownership  abilities: 
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//:  Cl  6 : OwnerStackTest . cpp 
//{L}  AutoCounter 
#include  "AutoCounter . h" 

#include  "OwnerStack . h" 

#include  /require . h" 

#include  <iostream> 

#include  <fstream> 

#include  <string> 
using  namespace  std; 

int  main  ( ) { 

Stack<AutoCounter>  ac;  //  Ownership  on 
Stack<AutoCounter>  ac2  (false);  //  Turn  it  off 
AutoCounter*  ap; 
for(int  i = 0;  i < 10;  itt)  { 
ap  = AutoCounter :: create  0 ; 
ac . push (ap) ; 
if(i  % 2 ==  0) 
ac2 . push (ap) ; 


while  (ac2 ) 

cout  <<  ac2.pop()  <<  endl; 

//  No  destruction  necessary  since 
//  ac  "owns"  all  the  objects 
} ///:- 

The  ac2  object  doesn't  own  the  objects  you  put  i nto  it,  thus  ac  i s the 
"master"  container  which  takes  responsibility  for  ownership.  If, 
partway  through  the  I ifeti  me  of  a contai  ner,  you  want  to  change 
whether  a container  owns  its  objects,  you  can  do  so  using  owns( ) 

Itwould  also  be  possibleto  change  the  granularity  of  the 
ownership  so  that  it  is  on  an  object-by-object  basis,  but  that  will 
probably  make  the  solution  to  the  ownership  problem  more 
compi  ex  than  the  probi  em. 


Holding  objects  by  value 

Actually  creating  a copy  of  the  objects  inside  a generic  container  is 
a complex  problem  if  you  don't  have  templates.  With  templates. 
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things  are  relatively  simple  - you  just  say  that  you  are  holding 
objects  rather  than  poi  nters: 

//:  Cl  6 : ValueStack . h 

//  Holding  objects  by  value  in  a Stack 
#ifndef  VALUE STACK_H 
#define  VALUESTACK_H 
#include  /require . h" 

template<class  T,  int  ssize  = 100> 
class  Stack  { 

//  Default  constructor  perforins  object 
//  initialization  for  each  element  in  array: 

T stack [ssize] ; 
int  top; 
public : 

Stack  0 : top ( 0 ) { } 

//  Copy-constructor  copies  object  into  array: 
void  push (const  T&  x)  { 

require (top  < ssize,  "Too  many  push()es"); 
stack [top++]  = x; 

} 

T peekO  const  { return  stack  [top];  } 

//  Object  still  exists  when  you  pop  it; 

//  it  just  isn't  available  anymore: 

T popO  { 

require (top  > 0,  "Too  many  pop()s"); 
return  stack [ — top]; 


}; 

#endif  //  VALUESTACK_H  ///:- 

The  copy  constructor  for  the  contained  objects  does  most  of  the 
work  by  passing  and  returning  the  objects  by  value.  Inside  push( ) 
storage  of  the  object  onto  the  Stack  array  is  accomplished  with 
T::operator^To  guarantee  that  it  works,  a class  called  SelfCounter 
keeps  track  of  object  creations  and  copy-constructions: 

//:  Cl  6 : Self Counter . h 
#ifndef  SELFCOUNTER_H 
#define  SELFCOUNTER_H 
#include  "ValueStack . h" 

#include  <iostream> 
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class  SelfCounter  { 
static  int  counter; 
int  id; 
public : 

Self Counter ( ) : id (counter++)  { 

std::cout  <<  "Created:  " <<  id  <<  std::endl; 

} 

SelfCounter (const  SelfCounter&  rv)  : id(rv.id){ 
std::cout  <<  "Copied:  " <<  id  <<  std::endl; 

} 

SelfCounter  operator= (const  SelfCounter&  rv)  { 
std::cout  <<  "Assigned  " <<  rv.id  <<  " to  " 

<<  id  <<  std::endl; 
return  *this; 

} 

-Self Counter ( ) { 

std::cout  <<  "Destroyed:  "<<  id  <<  std::endl; 

} 

friend  std : : ostream&  operator<< ( 

std : : ostream&  os,  const  SelfCounter&  sc) { 
return  os  <<  "SelfCounter:  " <<  sc. id; 


}; 

#endif  //  SELFCOUNTER_H  ///:- 

//:  Cl  6 : Self Counter . cpp  {0} 

#include  "SelfCounter . h" 

int  Self Counter :: counter  = 0;  ///:- 

//:  Cl  6 : ValueStackTest . cpp 
//{L}  SelfCounter 
#include  "ValueStack . h" 

#include  "SelfCounter . h" 

#include  <iostreain> 
using  namespace  std; 

int  main  ( ) { 

Stack<Self Counter>  sc; 
for(int  i = 0;  i < 10;  i++) 
sc . push (SelfCounter ( ) ) ; 

//  OK  to  peekO,  result  is  a temporary: 
cout  <<  sc. peek  0 <<  endl; 

for(int  k = 0;  k < 10;  k++) 
cout  <<  sc. pop  0 <<  endl; 
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} III-.- 


When  a Stack  container  is  created,  the  default  constructor  of  the 
contained  object  is  called  for  each  object  in  the  array.  You'll  initially 
see  100  SelfCounterobjects  created  for  no  apparent  reason,  but  this 
isjust  the  array  initialization.  This  can  be  a bit  expensive,  but 
there'sno  way  around  it  in  a simple  design  I ike  this.  An  even  more 
complex  situation  arises  if  you  make  the  Stack  more  general  by 
allowing  the  size  to  grow  dynamically,  because  in  the 
implementation  shown  above  this  would  involve  creating  anew 
(larger)  array,  copying  the  old  array  to  the  new,  and  destroying  the 
old  array  (this  is,  in  fact,  what  the  Standard  C++ Library  vector 
class  does). 


Introducing  iterators 

A n iterator  \ s an  object  that  moves  through  a contai  ner  of  other 
objects  and  selects  them  one  at  a time,  without  providing  direct 
access  to  the  i mplementation  of  that  container.  Iterators  provide  a 
standard  way  to  access  elements,  whether  or  not  a container 
providesa  way  to  access  the  elementsdirectly.  You  will  see 
iterators  used  most  often  in  association  with  container  classes,  and 
iterators  are  a fundamental  concept  in  the  design  and  use  of  the 
Standard  C++ containers,  which  are  fully  described  in  Volume2of 
this  book  (down  load  able  from  www.BruceEckd.com).  An  iterator  is 
also  a kind  of  design  pattern,  which  isthesubjectof  a chapter  in 
Volume  2. 

I n many  ways,  an  iterator  is  a "smart  pointer,"  and  in  fact  you'll 
notice  that  iterators  usually  mimic  most  pointer  operations.  Unlike 
a poi  nter,  however,  the  iterator  is  designed  to  be  safe,  so  you're 
much  less  I i kely  to  do  the  equi  val ent  of  wal ki  ng  off  the  end  of  an 
array  (or  if  you  do,  you  find  out  about  it  more  easily). 

C onsi  d er  the  f i rst  exam p I e i n th i s chapter.  H ere  i t i s w i th  a si  m p I e 
iterator  added: 
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//:  Cl  6 : IterIntStack . cpp 

//  Simple  integer  stack  with  iterators 

//{L}  fibonacci 

#include  "fibonacci . h" 

#include  /require . h" 

#include  <iostream> 
using  namespace  std; 

class  intStack  { 

enum  { ssize  = 100  }; 
int  stack [ssize] ; 
int  top; 
public : 

intStack 0 : top(O)  {} 

void  push (int  i)  { 

require (top  < ssize,  "Too  many  push()es"); 
stack[topt+]  = i; 

} 

int  popO  { 

require (top  > 0,  "Too  many  pop()s"); 
return  stack [ — top]; 

} 

friend  class  intStackIter ; 

}; 


//  An  iterator  is  like  a "smart"  pointer: 
class  IntStackIter  { 

IntStack&  s; 
int  index; 
public : 

IntStackIter ( IntStack&  is)  : s(is),  index (0)  {} 

int  operator++()  { //  Prefix 
require ( index  < s.top, 

"iterator  moved  out  of  range"); 
return  s . stack [++index] ; 

} 

int  operator++ ( int ) { //  Postfix 

require ( index  < s.top, 

"iterator  moved  out  of  range"); 
return  s . stack [ index++] ; 


}; 


int  main  ( ) { 

IntStack  is; 
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for(int  i = 0;  i < 20;  i++) 
is.push(fibonacci (i) ) ; 

//  Traverse  with  an  iterator: 

IntStackIter  it (is); 
for(int  j = 0;  j < 20;  j++) 

cout  <<  it++  <<  endl; 

} ///:- 

ThelntStacklteitias  been  created  to  work  only  with  an  IntStack 
Noticethat  IntStackIteiisafriendof  IntStack  which  gives  it 
access  to  al  I the  pri  vateel  ements  of  I ntStack 

Likea  pointer,  IntStackItefsjob  isto  move  through  an  IntStack 
and  retrieve  values.  In  this  simple  example,  the  I ntStackIteican 
move  only  forward  (using  both  the  pre-  and  postfix  forms  of  the 
operator+-$.  H owever,  there  is  no  boundary  to  the  way  an  iterator 
can  be  defi  ned,  other  than  those  i mposed  by  the  constrai  nts  of  the 
container  it  works  with.  It  is  perfectly  acceptable  (within  the  limits 
of  the  underlying  container)  for  an  iterator  to  move  around  in  any 
way  within  its  associated  container  and  to  cause  the  contained 
values  to  be  modified. 

It  is  customary  that  an  iterator  is  created  with  a constructor  that 
attaches  it  to  a single  contai  ner  object,  and  that  the  iterator  is  not 
attached  to  a different  container  during  its  lifetime.  (Iterators  are 
usually  small  and  cheap,  so  you  can  easily  make  another  one.) 

With  the  iterator,  you  can  traverse  the  elements  of  the  stack  without 
popping  them,  just  as  a pointer  can  move  through  the  el  ements  of 
an  array.  However,  the  iterator  knows  the  underlying  structure  of 
the  stack  and  how  to  traverse  the  el  ements,  so  even  though  you  are 
moving  through  them  by  pretending  to  "increment  a pointer," 
what's  going  on  underneath  is  more  involved.  That'sthe  key  to  the 
iterator:  It  is  abstracting  the  complicated  process  of  moving  from 
one  container  element  to  the  next  into  something  that  looks  likea 
pointer.  The  goal  is  for  ei/ery  iterator  in  your  program  to  have  the 
same  i nterface  so  that  any  code  that  uses  the  iterator  doesn't  care 
what  it's  pointing  to  - it  just  knows  that  it  can  reposition  all 
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iterators  the  same  way,  so  the  contai  ner  that  the  iterator  poi  nts  to  i s 
unimportant.  In  this  way  you  can  write  more  generic  code.  All  of 
the  contai  ners  and  algorithms  in  the  Standard  C-H- Library  are 
based  on  this  principleof  iterators. 

To  aid  in  making  things  more  generic,  itwould  be  nice  to  beableto 
say  "every  container  has  an  associated  class  called  iterator"  but 
thiswill  typically  cause  naming  problems.  The  solution  istoadd  a 
nested  iteratorclassto  each  container  (notice that  in  this  case, 
"iteratoi*'  begins  with  a lowercase  letter  so  that  it  conforms  to  the 
style  of  the  Standard  C++Library).  HereisIterIntStack.cppwith  a 
nested  iterator 

//:  Cl  6 : Nestediterator . cpp 

//  Nesting  an  iterator  inside  the  container 
//{L}  fibonacci 
#include  "fibonacci . h" 

#include  ".. /require . h" 

#include  <iostream> 

#include  <string> 
using  namespace  std; 


class  intStack  { 

enum  { ssize  = 100  }; 
int  stack [ssize] ; 
int  top; 
public : 

intStack 0 : top(O)  {} 

void  push (int  i)  { 

require (top  < ssize,  "Too  many  push()es"); 
stack[top++]  = i; 

} 

int  popO  { 

require (top  > 0,  "Too  many  pop()s"); 
return  stack [ — top]; 

} 

class  iterator; 
friend  class  iterator; 
class  iterator  { 
intStack&  s; 
int  index; 
public : 


16:  Introduction  to  Templates 


757 


iterator ( IntStack&  is)  : s(is),  index (0)  {} 

//  To  create  the  "end  sentinel"  iterator: 
iterator  ( IntStack&  is,  bool) 

: s(is),  index(s.top)  {} 
int  current  0 const  { return  s . stack [ index] ; } 

int  operator++()  { //  Prefix 
require ( index  < s.top, 

"iterator  moved  out  of  range"); 
return  s . stack [++index]  ; 

} 

int  operator++ ( int ) { //  Postfix 

require ( index  < s.top, 

"iterator  moved  out  of  range"); 
return  s . stack [ index++]  ; 

} 

//  Jump  an  iterator  forward 
iterators  operator+= ( int  amount)  { 
require ( index  + amount  < s.top, 

" Int Stack : : iterator : : ope rat or += ( ) " 

"tried  to  move  out  of  bounds"); 
index  +=  amount; 
return  *this; 

} 

//  To  see  if  you're  at  the  end: 
bool  operator== (const  iterators  rv)  const  { 
return  index  ==  rv. index; 

} 

bool  operator != (const  iterators  rv)  const  { 
return  index  !=  rv. index; 

} 

friend  ostreamS 

operator<< (ostreamS  os,  const  iterators  it)  { 
return  os  <<  it . current () ; 


iterator  begin ()  { return  iterator ( *this ) ; } 

//  Create  the  "end  sentinel": 

iterator  end()  { return  iterator ( *this , true);} 

}; 

int  main  ( ) { 

IntStack  is; 

for(int  i = 0;  i < 20;  i++) 
is.push(fibonacci  (i) ) ; 
cout  <<  "Traverse  the  whole  IntStack\n"; 
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IntStack ::  iterator  it  = is.beginO; 
while(it  !=  is.endO) 
cout  <<  it++  <<  endl; 

cout  <<  "Traverse  a portion  of  the  IntStack\n"; 

IntStack: : iterator 

start  = is.beginO,  end  = is.beginO; 
start  +=  5,  end  +=  15; 
cout  <<  "start  = " <<  start  <<  endl; 
cout  <<  "end  = " <<  end  <<  endl; 
while (start  !=  end) 

cout  <<  start+t  <<  endl; 

} ///:- 

When  making  a nested  friend  cl  ass,  you  must  go  through  the 
process  of  first  declari  ng  the  name  of  the  class,  then  declaring  it  as  a 
friend,  then  defining  the  cl  ass.  Otherwise,  the  compiler  will  get 
confused. 

Some  new  twists  have  been  added  to  the  iterator.  Thecurrent( ) 
member  function  produces  the  element  in  the  container  that  the 
iterator  is  currently  selecting.  You  can  "jump"  an  iterator  forward 
by  an  arbitrary  number  of  elements  using  operator+=Also,  you'll 
see  two  overloaded  operators:  ==and  !=  that  will  compare  one 
iterator  with  another.  These  can  compare  any  two 
lntStack::iteratoar,  but  they  are  primarily  intended  as  a test  to  see  if 
the  iterator  is  at  the  end  of  a sequence  in  the  same  way  that  the 
"real"  Standard  C++ Library  iterators  do.  The  idea  is  that  two 
iterators  define  a range,  including  the  first  element  pointed  to  by 
the  first  iterator  and  up  to  but  not  including  the  last  element 
pointed  to  by  the  second  iterator.  So  if  you  want  to  move  through 
the  range  defined  by  the  two  iterators,  you  say  something  I ike  this: 

while (start  !=  end) 

cout  <<  start++  <<  endl; 

where  startand  end  are  the  two  iterators  in  the  range.  Note  that  the 
end  iterator,  which  we  often  refer  to  as  the  end  sentinel,  is  not 
dereferenced  and  isthere  only  to  tell  you  that  you're  at  the  end  of 
the  sequence.  Thus  it  represents  "one  past  the  end." 
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Much  of  the  time  you'll  want  to  move  through  the  entire  sequence 
in  a container,  so  the  container  needs  some  way  to  produce  the 
iterators  i nd i cat!  ng  the  begi  nni  ng  of  the  sequence  and  the  end 
sent!  nel . H ere,  as  i n the  Standard  C ++  Li  brary,  these  iterators  are 
produced  by  the  container  member  functions  begi n(  )and  end( ) 
begin(  )usesthefirstiteratorconstructor  that  defaults  to  pointing 
at  the  beginning  of  the  container  (this  is  the  first  element  pushed  on 
the  stack).  However,  a second  constructor,  used  by  end( ) is 
necessary  to  create  the  end  sentinel  iterator  Being  "at  the  end" 
means  poi  nti  ng  to  the  top  of  the  stack,  because  top  always  i nd  i cates 
the  next  available  - but  unused  - space  on  the  stack.  This  iterator 
constructor  takes  a second  argument  of  type  booi,  which  is  a 
dummy  to  distinguish  the  two  constructors. 

The  Fibonacci  numbers  are  used  again  to  fill  theIntStackin 
main( ) and  iteratois  are  used  to  move  through  thewholeIntStack 
and  also  within  a narrowed  range  of  the  sequence. 

The  next  step,  of  course,  is  to  make  the  code  general  by 
tempi  ati  zing  it  on  the  type  that  it  holds,  so  that  instead  of  being 
forced  to  hold  only  intsyou  can  hold  any  type: 

//:  Cl  6 : IterStackTemplate . h 

//  Simple  stack  template  with  nested  iterator 
#ifndef  1TERSTACKTEMPLATE_H 
#define  1TERSTACKTEMPLATE_H 
#include  ".. /require . h" 

#include  <iostream> 

template<class  T,  int  ssize  = 100> 
class  StackTemplate  { 

T stack [ssize] ; 
int  top; 
public : 

StackTemplate ( ) : top(O)  {} 

void  push (const  T&  i)  { 

require (top  < ssize,  "Too  many  push()es"); 
stack[top++]  = i; 

} 

T popO  { 
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require (top  > 0,  "Too  many  pop()s"); 
return  stack [ — top]; 

} 

class  iterator;  //  Declaration  required 
friend  class  iterator;  //  Make  it  a friend 
class  iterator  { //  Now  define  it 
StackTemplate&  s; 
int  index; 
public : 

iterator (StackTemplate&  st):  s ( st ), index ( 0 ){ } 
//  To  create  the  "end  sentinel"  iterator: 
iterator (StackTemplate&  st,  bool) 

: s(st),  index(s.top)  {} 

T operator*])  const  { return  s . stack [ index] ; } 
T operator++()  { //  Prefix  form 
require ( index  < s.top, 

"iterator  moved  out  of  range"); 
return  s . stack [++index] ; 

} 

T operator++ ( int ) { //  Postfix  form 

require ( index  < s.top, 

"iterator  moved  out  of  range"); 
return  s . stack [ index++] ; 

} 

//  Jump  an  iterator  forward 
iterators  operator+= ( int  amount)  { 
require ( index  + amount  < s.top, 

" StackTemplate :: iterator :: operator+= ( ) " 

"tried  to  move  out  of  bounds"); 
index  +=  amount; 
return  *this; 

} 

//  To  see  if  you're  at  the  end: 
bool  operator== (const  iterators  rv)  const  { 
return  index  ==  rv. index; 

} 

bool  operator !=  (const  iterators  rv)  const  { 
return  index  !=  rv. index; 

} 

friend  std : : ostreamS  operator<<  ( 

std : : ostreamS  os,  const  iterators  it)  { 
return  os  <<  *it; 

} 

}; 

iterator  begin])  { return  iterator ( *this ) ; } 


16:  Introduction  to  Templates 


761 


//  Create  the  "end  sentinel": 

iterator  end()  { return  iterator ( *this , true);} 

}; 

#endif  //  ITERSTACKTEMPLATE_H  ///:- 

You  can  see  that  the  transformation  from  a regular  cl  ass  to  a 
templateis  reasonably  transparent.  This  approach  of  first  creating 
and  debugging  an  ordinary  class,  then  making  it  into  a template,  is 
generally  considered  to  be  easier  than  creating  the  tempi  ate  from 
scratch. 

Notice  that  instead  of  just  saying: 

friend  iterator;  //  Make  it  a friend 

This  code  has: 

friend  class  iterator;  //  Make  it  a friend 

This  is  important  becausethe  name  "iterator"  isal  ready  in  scope, 
from  an  included  file. 

Instead  of  thecurrent(  )member  function,  the iteratorhas an 
operator*to  select  the  current  element,  which  makes  the  iterator 
look  more  I ike  a pointer  and  is  a common  practice. 

Here's  the  revised  example  to  test  the  tempi  ate: 

// : C16 : IterStackTemplateTest . cpp 
//{L}  fibonacci 
#include  "fibonacci . h" 

#include  " IterStackTemplate . h" 

#include  <iostream> 

#include  <fstream> 

#include  <string> 
using  namespace  std; 

int  main  ( ) { 

StackTemplate<int>  is; 
for(int  i = 0;  i < 20;  it+) 
is.push(fibonacci  (i) ) ; 

//  Traverse  with  an  iterator: 
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cout  <<  "Traverse  the  whole  StackTemplateXn" ; 
StackTemplate<int>  ::  iterator  it  = is.beginO; 
while(it  !=  is.endO) 
cout  <<  it++  <<  endl; 
cout  <<  "Traverse  a portion\n"; 

StackTemplate<int> : : iterator 

start  = is.beginO,  end  = is.beginO; 
start  +=  5,  end  +=  15; 
cout  <<  "start  = " <<  start  <<  endl; 
cout  <<  "end  = " <<  end  <<  endl; 
while (start  !=  end) 

cout  <<  start++  <<  endl; 
if stream  in  ( " TterStackTemplateTest . cpp" ) ; 
assure  (in,  "TterStackTemplateTest . cpp" ) ; 
string  line; 

StackTemplate<string>  strings; 
while (getline (in,  line)) 
strings . push ( line ) ; 

StackTemplate<string> : : iterator 

sb  = strings . begin  0 , se  = strings . end () ; 
while ( sb  ! = se ) 

cout  <<  sb++  <<  endl; 

} ///:- 

The  fi  rst  use  of  the  iterator  just  marches  it  from  begi  nni  ng  to  end 
(and  shows  that  the  end  sentinel  works  properly).  In  the  second 
usage,  you  can  see  how  iterators  allow  you  to  easily  specify  a range 
of  elements  (the containers  and  iterators  in  the  Standard  C++ 

Li  brary  use  this  concept  of  ranges  al  most  everywhere).  The 
overloaded  operator+=movesthestartand  end  iterators  to 
positions  in  themiddleof  the  range  of  the  elements  in  is,  and  these 
elements  are  printed  out.  Notice  in  the  output  that  the  end  sentinel 
isnotincluded  in  the  range,  thus  it  can  be  one  past  the  end  of  the 
range  to  let  you  know  you've  passed  the  end  - but  you  don't 
dereference  the  end  sentinel,  or  else  you  can  end  up  dereferencing  a 
null  pointer.  (I've  put  guarding  in  theStackTemplate::iteratqibut 
in  the  Standard  C++ Li  brary  containers  and  iterators  there  is  no 
such  code  - for  efficiency  reasons  - so  you  must  pay  attention.) 
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Lastly,  to  verify  that  the  StackT emplatBworks  with  class  objects, 
one  is  instantiated  for  string  and  filled  with  the  lines  from  the 
source-codefile,  which  are  then  printed  out. 

Stack  with  iterators 

Wecan  repeat  the  process  with  the  dynamically-sized  Stack  class 
that  has  been  used  as  an  examplethroughout  the  book.  Here's  the 
Stack  cl  ass  with  a nested  iterator  folded  into  the  mix: 

//:  C16:TStack2.h 

//  Templatized  Stack  with  nested  iterator 
#ifndef  TSTACK2_H 
#define  TSTACK2_H 

template<class  T>  class  Stack  { 
struct  Link  { 

T*  data; 

Link*  next; 

Link(T*  dat.  Link*  nxt) 

: data (dat),  next  (nxt)  {} 

}*  head; 
public : 

Stack  ( ) : head ( 0 ) { } 

-Stack  ( ) ; 

void  push(T*  dat)  { 

head  = new  Link (dat,  head); 

} 

T*  peek ( ) const  { 

return  head  ? head->data  : 0; 

} 

T*  pop ( ) ; 

//  Nested  iterator  class: 

class  iterator;  //  Declaration  required 
friend  class  iterator;  //  Make  it  a friend 
class  iterator  { //  Now  define  it 
Stack : : Link*  p ; 
public : 

iterator (const  Stack<T>&  tl)  : p(tl.head)  {} 

//  Copy-constructor: 

iterator (const  iterators  tl)  : p(tl.p)  {} 

//  The  end  sentinel  iterator: 
iterator  ( ) : p ( 0 ) { } 
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//  operator++  returns  boolean  indicating  end: 
bool  operator++()  { 
if (p->next ) 
p = p->next; 

else  p = 0;  //  Indicates  end  of  list 
return  bool (p) ; 


bool  operator++ ( int ) { return  operator++ ( ) ; } 

T*  current  0 const  { 
if  ( ! p)  return  0 ; 
return  p->data; 

} 

//  Pointer  dereference  operator: 

T*  operator->()  const  { 
require (p  ! = 0 , 

"PStack: :iterator: : operator->returns  0") ; 
return  current  (); 


T*  operator* 0 const 
//  bool  conversion  fo 
operator  bool()  const 
//  Comparison  to  test 
bool  operator== (const 
return  p ==  0 ; 

} 

bool  operator != (const 
return  p !=  0; 


return  current ();  } 

conditional  test: 

{ return  bool  (p) ; } 

for  end: 

iterators)  const  { 


iterators)  const  { 


iterator  begin  ()  const  { 
return  iterator ( *this ) ; 

} 

iterator  end()  const  { return  iterator ();  } 


template<class  T>  Stack<T> : : ~Stack ( ) { 

while (head) 
delete  pop ( ) ; 

} 

template<class  T>  T*  Stack<T> : : pop ( ) { 

if (head  ==  0)  return  0; 

T*  result  = head->data; 

Link*  oldHead  = head; 
head  = head->next; 
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delete  oldHead; 
return  result; 

} 

#endif  //  TSTACK2_H  ///:- 

You'l  I al  SO  noti  ce  the  cl  ass  has  been  changed  to  su  pport  ownershi  p, 
whi  ch  works  now  because  the  cl  ass  knows  the  exact  type  (or  at 
leastthe  base  type,  which  will  work  assuming  virtual  destructors 
are  used).  The  default  is  for  the  container  to  destroy  its  objects  but 
you  are  responsible  for  any  pointers  that  you  pop(  \ 

The  iterator  is  simple,  and  physically  very  small  -the  size  ofa 
single  pointer.  When  you  create  an  iterator  it's  initialized  to  the 
head  of  the  linked  list,  and  you  can  only  increment  itforward 
through  the  I ist.  If  you  want  to  start  over  at  the  beginning,  you 
create  a new  iterator,  and  if  you  want  to  remember  a spot  in  the  list, 
you  create  a new  iterator  from  the  existing  iterator  pointing  at  that 
spot  (using  the  iterator's  copy-constructor). 

To  cal  I functions  for  the  object  referred  to  by  the  iterator,  you  can 
usethecurrent(  )function,  the  operator*  or  the  pointer  dereference 
operator- >(a  common  sight  in  iterators).  The  latter  has  an 
implementation  that  looks  identical  to  current(  )because  it  returns  a 
poi  nter  to  the  current  object,  but  is  different  because  the  poi  nter 
dereference  operator  performs  the  extra  I evel  s of  dereferenci  ng  (see 
Chapter  12). 

The  iteratorclass  follows  the  form  you  saw  in  the  prior  example, 
class  iterators  nested  insidethe container  class,  it  contains 
constructors  to  create  both  an  iterator  poi  nti  ng  at  an  element  in  the 
container  and  an  "end  sentinel"  iterator,  and  the  container  class  has 
thebegin(  )and  end(  )methodsto  produce  these  iterators.  (When 
you  learn  the  more  about  the  Standard  C-H- Library,  you'll  see  that 
the  names  iterator  begin( ) and  end(  )that  are  used  here  were 
clearly  lifted  standard  container  cl  asses.  At  the  end  of  this  chapter, 
you'll  seethatthisenablesthesecontainer  classesto  beused  as  if 
they  were  Standard  C-H-Library  container  classes.) 
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The  entire  implementation  iscontained  in  the  header  file,  so  there's 
no  separate  cpp  file.  Here'sasmall  test  that  exercises  the  iterator: 

//:  Cl  6 : TStack2Test . cpp 
#include  "TStack2.h" 

#include  /require . h" 

#include  <iostream> 

#include  <fstream> 

#include  <string> 
using  namespace  std; 

int  main  ( ) { 

if stream  file ("TStack2Test . cpp" ) ; 
assure  (file,  "TStack2Test. cpp" ) ; 

Stack<string>  textlines; 

//  Read  file  and  store  lines  in  the  Stack: 
string  line; 

while (getline (file,  line)) 

textlines . push (new  string (line) ) ; 
int  i = 0; 

//  Use  iterator  to  print  lines  from  the  list: 

Stack<string> :: iterator  it  = textlines . begin ()  ; 
Stack<string> :: iterator*  it2  = 0; 
while  (it  !=  textlines . end ( ) ) { 

cout  <<  it->c_str()  <<  endl; 
it ++ ; 

if  (++i  ==  10)  //  Remember  10th  line 

it2  = new  Stack<string> :: iterator  ( it ) ; 

} 

cout  <<  ( *it2 ) ->c_str ( ) <<  endl; 
delete  it2; 

} ///:- 

A Stack  is  instantiated  to  hold  stringobjectsand  filled  with  lines 
from  a file.  Then  an  iterator  is  created  and  used  to  move  through 
the  sequence.  Thetenth  line  is  remembered  by  copy-constructing  a 
second  iterator  from  the  first;  laterthis  line  is  printed  and  the 
iterator  - created  dynamically  - is  destroyed.  Here,  dynamic  object 
creation  is  used  to  control  the  I ifeti  me  of  the  object. 
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PStash  with  iterators 

For  most  container  classes  it  makes  sense  to  have  an  iterator.  Here's 
an  iterator  added  to  the  PStash  cl  ass: 

//:  C16:TPStash2.h 

//  Templatized  PStash  with  nested  iterator 
#ifndef  TPSTASH2_H 
#define  TPSTASH2_H 
#include  /require . h" 

#include  <cstdlib> 

template<class  T,  int  incr  = 20> 
class  PStash  { 
int  quantity; 
int  next ; 

T**  storage; 

void  inflate  (int  increase  = incr); 
public : 

PStashO  : quantity  (0),  storage  (0),  next(O)  {} 

-PStash  ( ) ; 

int  add(T*  element); 

T*  operator []  (int  index)  const; 

T*  remove (int  index); 

int  count  0 const  { return  next;  } 

//  Nested  iterator  class: 
class  iterator;  //  Declaration  required 
friend  class  iterator;  //  Make  it  a friend 
class  iterator  { //  Now  define  it 
PStash&  ps; 
int  index; 
public : 

iterator (PStash&  pStash) 

: ps (pStash)  , index (0)  {} 

//  To  create  the  end  sentinel: 
iterator (PStash&  pStash,  bool) 

: ps (pStash) , index (ps . next ) {} 

//  Copy-constructor: 
iterator (const  iterators  rv) 

: ps(rv.ps),  index (rv . index)  {} 
iterators  operator= (const  iterators  rv)  { 
ps  = rv.ps; 
index  = rv. index; 
return  *this; 
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iterators  operator++()  { 

require (++index  <=  ps.next, 

"PStash: :iterator: :operator++  " 

"moves  index  out  of  bounds"); 
return  *this; 

} 

iterators  operator++ ( int ) { 

return  operator++ ( ) ; 

} 

iterators  operator — ()  { 

require ( — index  >=  0, 

"PStash :: iterator :: operator — " 

"moves  index  out  of  bounds"); 
return  *this; 

} 

iterators  operator — (int)  { 
return  operator — (); 

} 

//  Jump  interator  forward  or  backward: 

iterators  operator+= ( int  amount)  { 
require ( index  + amount  < ps.next  SS 
index  + amount  >=  0, 

"PStash: :iterator: :operator+=  " 

"attempt  to  index  out  of  bounds"); 
index  +=  amount; 
return  *this; 

} 

iterators  operator-= ( int  amount)  { 
require ( index  - amount  < ps.next  SS 
index  - amount  >=  0, 

"PStash: :iterator: :operator-=  " 

"attempt  to  index  out  of  bounds"); 
index  -=  amount; 
return  *this; 

} 

//  Create  a new  iterator  that's  moved  forward 

iterator  operatorf  ( int  amount)  const  { 
iterator  ret(*this); 

ret  +=  amount;  //  op+=  does  bounds  check 
return  ret; 

} 

T*  current  0 const  { 

return  ps . storage [ index] ; 
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T*  operator* 0 const  { return  current  ();  } 

T*  operator->()  const  { 

require (ps . storage [ index]  !=  0, 

"PStash: :iterator: : operator->returns  0") ; 
return  current]); 

} 

//  Remove  the  current  element: 

T*  remove  ( ) { 

return  ps . remove (index) ; 

} 

//  Comparison  tests  for  end: 
bool  operator== (const  iterators  rv)  const  { 
return  index  ==  rv. index; 

} 

bool  operator != (const  iterators  rv)  const  { 
return  index  !=  rv. index; 


iterator  begin])  { return  iterator  ( *this ) ; } 

iterator  end])  { return  iterator  ( *this , true);} 


//  Destruction  of  contained  objects: 
template<class  T,  int  incr> 

PStash<T,  incr> : : ~PStash ( ) { 

for  (int  i = 0;  i < next;  i++)  { 

delete  storage [i];  //  Null  pointers  OK 
storage [i]  = 0;  //  Just  to  be  safe 

} 

delete  [] storage; 

} 

template<class  T,  int  incr> 
int  PStash<T,  incr> : : add (T*  element)  { 
if  (next  >=  quantity) 
inflate ( ) ; 

storage [next++]  = element; 
return (next  - 1);  //  Index  number 


template<class  T,  int  incr>  inline 

T*  PStash<T,  incr> :: operator [ ] (int  index)  const  { 
require ( index  >=  0, 

"PStash :: operator [ ] index  negative"); 
if (index  >=  next) 
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return  0;  //  To  indicate  the  end 
require (storage [index]  !=  0, 

"PStash :: operator [ ] returned  null  pointer"); 
return  storage [ index]  ; 

} 

template<class  T,  int  incr> 

T*  PStash<T,  incr> :: remove ( int  index)  { 

//  operator []  performs  validity  checks: 

T*  V = operator [] (index); 

//  "Remove"  the  pointer: 
storage [ index]  = 0; 
return  v; 

} 

template<class  T,  int  incr> 

void  PStash<T,  incr> :: inf late  ( int  increase)  { 
const  int  tsz  = sizeof(T*); 

T**  St  = new  T* [quantity  + increase]; 

memset (st,  0,  (quantity  + increase)  * tsz); 

memcpy(st,  storage,  quantity  * tsz); 

quantity  +=  increase; 

delete  [] storage;  //  Old  storage 

storage  = st;  //  Point  to  new  memory 

} 

#endif  //  TPSTASH2_H  ///:- 

Most  of  this  file  is  a fairly  straightforwar(d  translation  of  both  the 
previous  PStash an(d  the  nested  iteratorintoatennplate.  Thistime, 
however,  the  operators  return  references  to  the  current  iterator, 
which  is  the  more  typical  and  flexible  approach  to  take. 

The  destructor  cal  Is  deletefor  all  contained  pointers,  and  because 
thetype  is  captured  by  the  tempi  ate,  proper  destruction  will  take 
place.  You  should  be  aware  that  if  the  container  holds  pointers  to  a 
base-class  type,  that  type  should  havea  virtual  destructor  to  ensure 
proper  cleanup  of  derived  objects  whose  addresses  have  been 
upcast  when  placing  them  in  the  container. 

ThePStash::iteratoifollowstheiterator  model  of  bonding  to  a 
si ngl e contai  ner  object  for  its  I ifeti  me.  I n add iti on,  the  copy- 
constructor  allows  you  to  make  a new  iterator  pointing  at  the  same 
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location  as  the  ©d  sting  iterator  that  you  create  it  from,  effectively 
making  a bookmark  into  the  container.  The operator+=and 
operator-=member  functions  allow  you  to  move  an  iterator  by  a 
number  of  spots,  while  respecti  ng  the  boundaries  of  the  container. 
The  overloaded  increment  and  decrement  operators  move  the 
iterator  by  one  place.  Theoperator+produces  a new  iterator  that's 
moved  forward  by  the  amount  of  the  addend.  Asinthe  previous 
example,  the  poi  nter  dereference  operators  are  used  to  operate  on 
the  element  the  iterator  is  referring  to,  and  remove(  )destroys  the 
current  object  by  calling  the  container's  remove( ) 

The  same  ki  nd  of  code  as  before  (a  la  the  Standard  C++  Li  brary 
contai  ners)  is  used  for  creati  ng  the  end  senti  nel : a second 
constructor,  the  contai  ner'send( ) member  function,  and 

operator==and  operator !=for  comparison. 

Thefollowing  example  creates  and  tests  two  different  kindsof 
Stash  objects,  one  for  a new  cl  ass  cal  led  Intthat  announces  its 
construction  and  destruction  and  one  that  holds  objects  of  the 
Standard  library  string  cl  ass. 

//:  Cl  6 : TPStash2Test . cpp 
#include  "TPStash2.h" 

#include  ".. /require . h" 

#include  <iostream> 

#include  <vector> 

#include  <string> 
using  namespace  std; 

class  int  { 
int  i ; 
public : 

int (int  ii  = 0)  : i(ii)  { 

cout  <<  ">"  <<  i <<  ' 

} 

~int()  { cout  <<  <<  i <<  ' } 

operator  int()  const  { return  i;  } 
friend  ostream& 

operator<< (ostream&  os,  const  int&  x)  { 
return  os  <<  "int:  " <<  x.i; 
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} 

friend  ostream& 

operator<< (ostream&  os,  const  Int*  x)  { 
return  os  <<  "Int:  " <<  x->i; 


}; 

int  main  ( ) { 

{ //  To  force  destructor  call 
PStash<Int>  ints; 
for(int  i = 0;  i < 30;  itt) 
ints. add (new  Int (i) ) ; 
cout  <<  endl; 

PStash<Int> :: iterator  it  = ints . begin ()  ; 
it  +=  5; 

PStash<Int> :: iterator  it2  = it  + 10; 
for(;  it  !=  it2;  it++) 

delete  it.removeO;  //  Default  removal 
cout  <<  endl; 

for(it  = ints  . begin  0;  it  !=  ints  . end  ();  it++) 
if(*it)  //  Remove ( ) causes  "holes" 
cout  <<  *it  <<  endl; 

} //  "ints"  destructor  called  here 

cout  <<  "\n \n"; 

if stream  in (" TP Stas h2 Test . cpp" ) ; 
assure (in,  " TP Stas h2 Test. cpp" ) ; 

//  Instantiate  for  String: 

PStash<string>  strings; 
string  line; 

while (getline (in,  line)) 

strings . add (new  string ( line )) ; 

PStash<string> :: iterator  sit  = strings . begin () ; 
for(;  sit  !=  strings . end () ; sit++) 
cout  <<  **sit  <<  endl; 
sit  = strings . begin  0 ; 
int  n = 26; 
sit  +=  n; 

for(;  sit  !=  strings . end () ; sit++) 

cout  <<  n++  <<  ":  " <<  **sit  <<  endl; 

} ///:- 

For  convenience,  Int  has  an  associated  ostream  operator<<or  both 
an  lnt&  and  an  Int*. 
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The  first  block  of  codein  main(  )issurrounded  by  braces  to  force 
the  destruction  of  thePStash<lnt>and  thustheautomatic  cleanup 
by  that  destructor.  A range  of  elennents  is  rennoved  and  deleted  by 
hand  to  show  that  the  PStash  cleans  up  the  rest. 

For  both  instances  of  PStasK  an  iterator  is  created  and  used  to 
move  through  the  container.  Noticethe  elegance  produced  by 
using  these  constructs;  you  aren't  assailed  with  the  implementation 
details  of  using  an  array.  You  tell  the  container  and  iterator  objects 
what  to  6o,  not  how.  This  makes  the  solution  easier  to 
conceptualize,  to  build,  and  to  modify. 


Why  iterators? 

U p unti  I now  you've  seen  the  mechanics  of  iterators,  but 
understanding  why  they  are  so  important  takes  a more  complex 
example. 

It's  common  to  see  polymorphism,  dynamic  object  creation,  and 
containers  used  together  in  a true  object-oriented  program. 
Containers  and  dynamic  object  creation  solvethe  problem  of  not 
knowing  how  many  or  what  type  of  objects  you 'I  I need.  And  if  the 
container  is  configured  to  hold  pointers  to  base-class  objects,  an 
upcast  occurs  every  ti  me  you  put  a derived -cl ass  poi  nter  into  the 
container  (with  the  associated  code  organization  and  extensibility 
benefits).  As  the  final  code  in  Volume  1 of  this  book,  this  example 
will  also  pull  together  various  aspects  of  everything  you've  learned 
so  far  - if  you  can  follow  this  example,  then  you're  ready  for 
Volume  2. 

Suppose  you  are  creating  a program  that  allows  the  user  to  edit  and 
produce  different  kinds  of  drawings.  Each  drawing  is  an  object  that 
contains  a collection  of  Shape  objects: 

//:  C16:Shape.h 
#ifndef  SHAPE_H 
#define  SHAPE_H 
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#include  <iostream> 
#include  <string> 


class  Shape  { 
public : 

virtual  void  draw()  = 0; 
virtual  void  erase  ()  = 0; 
virtual  -Shape  ()  {} 


class  Circle  : public  Shape  { 
public : 

Circle  ( ) { } 

-Circle  0 { std::cout  <<  "Circle :: -CircleXn" ; } 

void  drawO  { std::cout  <<  "Circle  ::  draw\n" ; } 
void  erase  0 { std::cout  <<  "Circle :: eraseVn" ; } 


class  Square  : public  Shape  { 
public : 

Square ( ) { } 

-Square  0 { std::cout  <<  "Square :: -SquareXn" ; } 

void  drawO  { std::cout  <<  "Square  ::  draw\n" ; } 
void  erase  0 { std::cout  <<  "Square :: eraseVn" ; } 


class  Line  : public  Shape  { 
public : 

LineO  {} 

-LineO  { std::cout  <<  "Line  : : -Line\n" ; } 

void  drawO  { std::cout  <<  "Line  : : draw\n"  ; } 
void  erase  0 { std::cout  <<  "Line  : : eraseVn" ; } 

}; 

#endif  //  SHAPE_H  ///:- 

Thi  s uses  the  cl  assi  c structure  of  vi  rtual  functi  ons  i n the  base  cl  ass 
that  are  overridden  in  the  derived  class.  N otice  that  the  Shapeclass 
includes  a virtual  destructor,  something  you  should  automatically 
add  to  any  class  with  virtual  functi  ons.  If  a container  holds  pointers 
or  references  to  Shapeobjects,  then  when  the  virtual  destructors 
are  cal  led  for  those  objects  everything  will  be  properly  cleaned  up. 
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Each  different  type  of  drawing  in  the  following  example  makes  use 
of  adifferent  kind  of  templatized  container  class:  thePStashand 
Stackthat  have  been  defined  in  this  chapter,  and  thevectorclass 
from  the  Standard  C++ Library.  The  "use"'  of  the  containers  is 
extremely  simple,  and  in  general  inheritance  might  not  be  the  best 
approach  (composition  could  make  more  sense),  but  in  this  case 
i nheritance  is  a si  mpl e approach  and  it  doesn't  detract  from  the 
point  made  in  the  example. 

//:  Cl  6 : Drawing . cpp 

#include  <vector>  //  Uses  Standard  vector  too! 

#include  "TPStash2.h" 

#include  "TStack2.h" 

#include  "Shape. h" 
using  namespace  std; 

//  A Drawing  is  primarily  a container  of  Shapes: 
class  Drawing  : public  PStash<Shape>  { 
public : 

~Drawing()  { cout  <<  "~Drawing"  <<  endl;  } 

}; 


//  A Plan  is  a different  container  of  Shapes: 
class  Plan  : public  Stack<Shape>  { 
public : 

~Plan()  { cout  <<  "~Plan"  <<  endl;  } 

}; 


//  A Schematic  is  a different  container  of  Shapes: 
class  Schematic  : public  vector<Shape*>  { 
public : 

~Schematic()  { cout  <<  "~Schematic"  <<  endl;  } 

}; 

//  A function  template: 
template<class  iter> 

void  drawAll(iter  start,  iter  end)  { 
while (start  !=  end)  { 

( *start ) ->draw ( ) ; 
start++; 


} 
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int  main  ( ) { 

//  Each  type  of  container  has 
//  a different  interface: 

Drawing  d; 
d.add(new  Circle); 
d.add(new  Square); 
d.add(new  Line); 

Plan  p; 

p. push (new  Line); 
p.push(new  Square); 
p.push(new  Circle); 

Schematic  s; 

s . push_back (new  Square); 
s . push_back (new  Circle); 
s . push_back (new  Line); 

Shape*  sarray[]  = { 

new  Circle,  new  Square,  new  Line 

}; 

//  The  iterators  and  the  template  function 

//  allow  them  to  be  treated  generically: 

cout  <<  "Drawing  d:"  <<  endl; 

drawAll  (d . begin  0 , d.endO); 

cout  <<  "Plan  p:"  <<  endl; 

drawAll (p . begin ( ) , p . end ( ) ) ; 

cout  <<  "Schematic  s:"  <<  endl; 

drawAll  ( s . begin  0 , s.endO); 

cout  <<  "Array  sarray:"  <<  endl; 

//  Even  works  with  array  pointers: 
drawAll (sarray, 

sarray  + sizeof (sarray) /sizeof (*sarray) ) ; 
cout  <<  "End  of  main"  <<  endl; 

} ///:- 

The  different  types  of  containers  all  hold  pointersto  Shapeand 
pointers  to  upcast  objects  of  classes  derived  from  Shape  However, 
because  of  polymorphism,  the  proper  behavior  still  occurswhen 
the  virtual  functions  are  cal  led. 

N ote  that  sarray,  the  array  of  Shape*  can  al  so  be  thought  of  as  a 
container. 
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Function  templates 

In  drawAII(  )you  see  something  new.  So  far  in  this  chapter,  we 
have  been  using  only  class  templates,  which  instantiate  new  classes 
based  on  one  or  more  type  parameters.  However,  you  can  as  easily 
cr^te  function  templates,  which  create  new  functions  based  on  type 
parameters.  The  reason  you  create  a function  template  is  the  same 
reason  you  usefor  a cl  ass  tempi  ate:  You're  trying  to  create  generic 
code,  and  you  do  this  by  delaying  the  specification  of  one  or  more 
types.  You  just  want  to  say  that  these  type  parameters  support 
certain  operations,  not  exactly  what  types  they  are. 

Thefunction  templatedrawAII(  )can  bethought  of  as  an  algorithm 
(and  this  is  what  most  of  thefunction  templates  in  the  Standard 
C++Library  are  called).  It  just  says  how  to  do  something  given 
iterators  descri  bi  ng  a range  of  elements,  as  long  as  these  iterators 
can  be  dereferenced,  incremented,  and  compared.  These  are  exactly 
the  kind  of  iterators  we  have  been  developing  in  this  chapter,  and 
also  - not  coincidentally -the  kind  of  iterators  that  are  produced  by 
the  containers  in  the  Standard  C++Library,  evidenced  by  the  use  of 
vector  i n th  i s exam  p I e. 

We'd  also  likedrawAII(  yto  beageneric  algorithm,  so  that  the 
contai  ners  can  be  any  type  at  al  I and  we  don't  haveto  writea  new 
version  of  the  algorithm  for  each  different  type  of  container.  Here's 
where  function  templates  are  essential,  because  they  automatically 
generate  the  specific  code  for  each  different  type  of  container.  But 
without  the  extra  indirection  provided  by  the  iterators,  this 
genericness  wouldn't  be  possible.  That's  why  iterators  are 
important;  they  allow  you  to  write  general-purpose  code  that 
involves  containers  without  knowing  theunderlying  structure  of 
the  contai  ner.  (Notice  that,  in  C-H-,  iterators  and  generic  algorithms 
require  function  templates  in  order  to  work.) 

You  can  seethe  proof  of  this  in  main( ) sincedrawAII(  )works 
unchanged  with  each  different  type  of  container.  And  even  more 
interesting,  drawAIK  )also  works  with  pointers  to  the  beginning 
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and  end  of  the  array  sarray.  Thi  s abi  I ity  to  treat  arrays  as  contai  ners 
is  integral  to  the  design  of  the  Standard  C++ Library,  whose 
algorithms  look  much  likedrawAII( ) 

Because  container  class  templates  are  rarely  subject  to  the 
inheritance  and  upcasting  you  see  with  "ordinary"  classes,  you'll 
almost  never  see  virtual  functions  in  container  classes.  Container 
class  reuse  is  implemented  with  templates,  not  with  inheritance. 


Summary 

Container  classes  are  an  essential  part  of  object-oriented 
programming.  They  are  another  way  to  simplify  and  hide  the 
details  of  a program  and  to  speed  the  process  of  program 
development.  In  addition,  they  provide  a great  deal  of  safety  and 
flexibility  by  replacing  the  primitive  arrays  and  relatively  crude 
data  structure  techniques  found  in  C. 

Because  the  cl  lent  programmer  needs  containers,  it's  essential  that 
they  be  easy  to  use.  This  is  wherethetemplatecomes  in.  With 
tempi  ates  the  syntax  for  sou  rce-code  reuse  (as  opposed  to  object- 
code  reuse  provided  by  inheritance  and  composition)  becomes 
trivial  enough  for  the  novice  user.  In  fact,  reusing  code  with 
templates  is  notably  easier  than  inheritance  and  composition. 

Although  you've  learned  about  creating  container  and  iterator 
classes  in  this  book,  in  practice  it's  much  more  expedient  to  learn 
the  contai  ners  and  iterators  in  the  Standard  C-H-Library,  si  nee  you 
can  expect  them  to  be  aval  I able  with  every  compiler.  As  you  will 
see  in  Volume  2 of  this  book  (downloadable from 
www.BruceEckd.com},  the  contai  ners  and  algorithms  in  the  Standard 
C-H-Library  will  virtually  always  fulfil  I your  needs  so  you  don't 
have  to  create  new  ones  yourself. 

The  issues  involved  with  container-class  design  have  been  touched 
upon  in  this  chapter,  but  you  may  have  gathered  that  they  can  go 
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much  further.  A complicated  container-class  library  may  cover  all 
sorts  of  additional  issues,  including  multithreading,  persistence 
and  garbage  col  lection. 


Exercises 

Solutions  to  selected  exercises  can  be  found  in  the  electronic  document  TheThinking  in  C++ Annotated 
Solution  Guide,  aval  I able  for  a small  feefromwww.BruceEckel.com. 

1.  Implement  the  inheritance  hierarchy  in  the 0 Shape 
diagram  in  this  chapter. 

2 . M od  ify  the  resu  It  of  Exerci  se  1 from  C hapter  15  to  use  the 
Stack  and  iteratorin  TStack2.h  instead  of  an  array  of 
Shape  pointers.  Add  destructors  to  the  class  hierarchy  so 
you  can  seethat  the  Shapeobjects  are  destroyed  when 
the  Stack  goes  out  of  scope. 

3.  M od  ify  TPStash.hso  that  the  increment  value  used  by 
inflate(  )can  be  changed  throughout  the  lifetime  of  a 
particular  container  object. 

4.  Mod  ify  TPStash.hso  that  the  increment  value  used  by 
inflate(  )automatically  resizes  itself  to  reduce  the 
number  of  times  it  needs  to  be  called.  For  example,  each 
time  it  is  called  it  could  doublethe  increment  value  for 
use  in  the  next  call.  Demonstrate thisfunctionality  by 
reporting  whenever  an  inflate!  )iscalled,  and  write  test 
code  in  main( ) 

5.  Tempi  atize  the  fibonacci(  function  on  the  type  of  value 
that  it  produces  (so  it  can  produce  long  float  etc.  instead 
of  just  int). 

6.  Using  the  Standard  C-H- Library  vector  as  an  underlying 
i mplementation,  create  a Settemplate  class  that  accepts 
only  one  of  each  type  of  object  that  you  put  into  it.  Make 
a nested  iteratorclass  that  supports  the  "end  sentinel" 
concept  i n thi  s chapter.  W rite  test  code  for  you  r Set  i n 
main! ) and  then  substitute  the  Standard  C-H- Library  set 
template  to  verify  that  the  behavior  is  correct. 


780 


Thinking  in  C-I--I- 


www.BruceEckel.com 


7.  Modify  A utoCounter.hso  that  it  can  be  used  as  a 
mennber  object  insideany  class  whose  creation  and 
destruction  you  want  to  trace.  Add  a string  mennber  to 
hold  thenameof  the  class.  Test  this  tool  inside  a cl  ass  of 
your  own. 

8.  Create  a version  of  0 wnerStack.hthat  uses  a Standard 
C++ Library  vector  as  its  underlying  implementation. 

You  may  need  to  look  up  some  of  the  member  functions 
of  vectorin  order  to  dothis(or  just  look  at  the  <vector> 
header  file). 

9.  Modify  ValueStack.hso that  it  dynamically  expandsas 
you  push(  )more  objects  and  it  runs  out  of  space.  Change 
V al  ueStackT est.cp|to  test  the  new  fu ncti  onal  ity. 

10.  Repeat  Exercise  9 but  use  a Standard  C++ Library  vector 
as  the  internal  implementation  of  the  ValueS  tack  Notice 
how  much  easier  this  is. 

11.  M od ify  V al ueStackT estcppso  that  it  uses  a Standard 
C++ Library  vector!  nstead  of  a Stack  in  main( ) Notice 
the  run-ti  me  behavior:  Does  the  vector  automatical  I y 
create  a bunch  of  default  objects  when  it  is  created? 

12.  ModifyTStack2.hso  that  it  uses  a Standard  C++Library 
vectoras  its  underlying  implementation.  Makesurethat 
you  don't  changethe  interface,  so  that! Stack2Test.cpp 
works  unchanged. 

13.  Repeat  Exercise  12  using  a Standard  C++ Library  stack 
instead  of  a vector  (you  may  need  to  look  up  information 
about  the  stack,  or  hunt  through  the  <stack>header  file). 

14.  Modify  TPStash2.hso  that  it  uses  a Standard  C++ 

Library  vectoras  its  underlying  implementation.  Make 
sure  that  you  don't  change  the  interface,  so  that 
TPStashZTestxppworks  unchanged. 

15.  In  lterlntStack.cppmodify  IntStackIteitogiveitan 
"end  sentinel"  constructor,  and  add  operator==and 
operator!^  In  main( ) use  an  iterator  to  move  through 
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the  el  ements  of  the  contai  ner  u nti  I you  reach  the  end 
sentinel. 

16.  Using TStack2.hTPStash2.h  and  Shape.K  instantiate 
Stack  and  PStash  containers  for  Shape*  fill  them  each 
with  an  assortment  of  upcast  Shape  pointers,  then  use 
iterators  to  move  through  each  container  and  call  draw( ) 
for  each  object. 

17.  TemplatizethelntclassinTPStash2Test.cppB0that  it 
hoi  ds  any  type  of  object  (feel  free  to  change  the  name  of 
the  cl  ass  to  something  more  appropriate). 

18.  TemplatizetheIntArrayclassin 

lostreamOperatorOverloading.cpfirom  Chapter  12, 
tempi atizing  both  thetypeof  object  that  is  contained  and 
the  size  of  the  internal  array. 

19.  Turn  ObjContainerin  Nested SmartPointer.cp|6rom 

Chapter  12  into  a template.  Test  it  with  two  different 
classes. 

20.  M odify  C 15:0  Stack.hand  C 15:0  StackT  est.cp(t>y 

templatizing  class  Stacksothat  it  automatically  multiply 
inherits  from  the  contained  class  and  from  Object  The 
generated  Stack  should  accept  and  produce  only  pointers 
of  the  contai  ned  type. 

2 1 . Repeat  Exerci  se  20  usi  ng  vector  I nstead  of  Stack 

22.  I nheri  t a cl  ass  Stri  ngV  ectoifrom  vector<void*>and 
redefine  the  push_back(  )and  operator[]member 

functions  to  accept  and  produce  only  string*(and 
perform  the  proper  casting).  Now  create  a tempi  ate  that 
will  automatically  make  a contai  ner  class  to  do  the  same 
thing  for  pointers  to  any  type.  This  technique  is  often 
used  to  reduce  code  bloat  from  too  many  template 
instantiations. 

23.  In  T PStash 2.h  add  and  test  an  operator-to 
PStash  ::iteratorfol  I owing  the  logic  of  operator-t 

24.  In  Drawing.cppadd  and  test  afunction  tempi  ate  to  call 
erase(  jmember  functions. 
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25.  (Advanced)  Modify  the  Stack  cl  ass  in  TStack2.hto  allow 
full  granularity  of  ownership:  Add  a flag  to  each  link 
indicating  whether  that  link  owns  the  object  it  points  to, 
and  supportthis  infornnation  inthepush(  )function  and 
destructor.  Add  mennber  functions  to  read  and  change 
the ownershi p for  each  link. 

26.  (Advanced)  Modify  PointeiToMemberOperator.cpp 

from  Chapter  12  so  that  the  FunctionO  bjecbnd 
operator->*are tempi ati zed  to  work  with  any  return  type 
(for  operator- >*  you'll  have  to  use  member  templates, 
described  in  Volume  2).  Add  and  test  support  for  zero, 
one  and  two  arguments  in  Dog  member  functions. 
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A:  Coding  Style 

This  appendix  is  not  about  indenting  and  piacement  of 
parentheses  and  curiy  braces,  aithough  that  wiii  be 
mentioned,  it  is  about  the  generai  guideiines  used  in 
this  book  for  organizing  the  code  iistings. 
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Although  many  of  these  issues  have  been  introduced  throughout 
the  book,  this  appendix  appears  at  the  end  so  it  can  be  assumed 
that  every  topic  isfair  game,  and  if  you  don't  understand 
something  you  can  look  it  up  in  the  appropriate  section. 

All  the  decisions  about  coding  style  in  this  book  have  been 
deliberately  considered  and  made,  sometimes  over  a period  of 
years.  Of  course,  everyone  has  their  reasons  for  organizing  codethe 
way  they  do,  and  I'm  just  trying  to  tel  I you  how  I arrived  at  mine 
and  the  constraints  and  environmental  factors  that  brought  me  to 
those  decisions. 


General 

In  the  text  of  this  book,  identifiers  (function,  variable,  and  class 
names)  are  set  in  bold.  Most  keywords  will  also  beset  in  bold, 
except  for  those  keywords  that  are  used  so  much  that  the  bolding 
can  become  tedious,  such  as  "class"  and  "virtual." 

I use  a particular  coding  style  for  the  examples  in  this  book.  It  was 
developed  over  a number  of  years,  and  was  partially  inspired  by 
BjarneStroustrup's  style  in  hisoriginal  The  C++  Programming 
Language+  The  subject  of  formatting  style  is  good  for  hours  of  hot 
debate,  so  I'll  just  say  I'm  not  trying  to  dictate  correct  style  via  my 
examples;  I have  my  own  motivation  for  using  thestylethat  I do. 
Because  C++ is  a free-form  programming  language,  you  can 
continue  to  use  whatever  style  you're  comfortable  with. 

That  said,  I will  note  that  it  is  important  to  have  a consistent 
formatting  stylewithin  a project.  If  you  search  theinternet,  you  will 
fi  nd  a nu  mber  of  tool  s that  can  be  used  to  reformat  al  I the  code  i n 
your  project  to  achieve  this  valuableconsistency. 


i|bid. 
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The  programs  in  this  book  are  files  that  are  automatically  extracted 
from  thetext  of  thebook,  which  allowsthemto  be  tested  to  ensure 
that  they  work  correctly.  Thus,  the  code fi  les  printed  i n the  book 
should  all  work  without  compile-time  errors  when  compiled  with 
an  implementation  that  conforms  to  Standard  C-H- (note  that  not  all 
compilers  support  all  language  features).  The  errors  that  s/iou/d 
cause  compile-time  error  messages  are  commented  out  with  the 
comment//!  so  they  can  be  easily  discovered  and  tested  using 
automatic  means.  Errors  discovered  and  reported  to  the  author  will 
appear  first  in  the  electron!  eversion  of  thebook  (at 
www.BruceEckd.com)  and  later  in  updates  of  thebook. 

Oneof  the  standards  in  this  book  isthat  all  programs  will  compile 
and  link  without  errors  (although  they  will  sometimes  cause 
warnings). To  thisend,  some  of  the  programs,  which  demonstrate 
only  a coding  example  and  don't  represent  stand-alone  programs, 
will  haveempty  main(  )functions,  likethis 

int  main  ( ) { } 

Thi s al  I ows  the  I i nker  to  compi ete  w ithout  an  error. 

The  standard  for  main(  )isto  return  an  int  but  Standard  C-h- 
statesthat  if  there  is  no  return  statement  inside  main( ) the 
compiler  will  automatically  generate  code  to  return  OThisoption 
(no  return  statement  in  main(  } will  be  used  in  this  book  (some 
compilers  may  still  generate  warnings  for  this,  but  those  are  not 
compliant  with  Standard  C-H-). 


File  names 

In  C,  it  has  been  traditional  to  name  header  files  (containing 
declarations)  with  an  extension  of  .h  and  implementation  files  (that 
cause  storage  to  deallocated  and  codeto  degenerated)  with  an 
extension  of  .c.  C-H- went  through  an  evolution.  It  was  first 
developed  on  Unix,  where  the  operating  system  was  aware  of 
upper  and  lower  casein  filenames.  The  original  filenames  were 


A:  Coding  Style 


787 


simply  capitalized  versions  of  the  C extensions:  .H  and  .C.Thisof 
course  didn't  work  for  operating  systems  that  didn't  distinguish 
upper  and  lower  case,  such  as  DOS.  DOS  C++ vendors  used 
extensions  of  hxx and  cxxfor  header  files  and  implementation  files, 
respectively,  or  hpp  and  cpp.  Later,  someone  figured  out  that  the 
only  reason  you  needed  a different  extension  for  a file  was  so  the 
compiler  could  determine  whether  to  compile  it  as  a C or  C++ file. 
Because  the  compiler  never  compiled  header  files  directly,  only  the 
implementation  file  extension  needed  to  be  changed.  The  custom, 
across  virtually  all  systems,  has  now  become  to  use  cpp  for 
implementation  files  and  h for  header  files.  Note  that  when 
including  Standard  C++ header  files,  the  option  of  having  no  file 
name  extension  is  used,  i.e.:  #include  <iostream> 


Begin  and  end  comment  tags 

A very  important  issue  with  this  book  isthatall  codethatyou  see 
in  the  book  must  be  verified  to  be  correct  (with  at  least  one 
compiler).  This  is  accomplished  by  automatically  extracting  the 
fi  I es  from  the  book.  T o faci I itate this,  al  I code  I i sti  ngs  that  are  meant 
to  decompiled  (as  opposed  to  codefragments,  of  which  there  are 
few)  have  comment  tags  at  the  beginning  and  end.  These  tags  are 
used  by  the  code-extraction  tool  ExtractCode.cppin  Volume2of 
this  book  (which  you  can  find  on  the  Web  site  www.BruceEckel.com) 
to  pull  each  code  listing  outof  theplain-ASCII  text  version  of  this 
book. 

The  end-listing  tag  simply  tells  ExtractCode.cppthat  it's  the  end  of 
the  listing,  but  the  begin-li  sting  tag  is  foil  owed  by  information 
about  what  subdirectory  the  file  belongs  in  (generally  organized  by 
chapters,  so  a file  that  belongs  in  Chapter  8 would  have  a tag  of 
COS),  followed  by  a colon  and  the  name  of  the  listing  file. 

Because  ExtractCode.cppalso  creates  a makefilefor  each 
subdirectory,  information  about  how  a program  is  made  and  the 
command-line  used  to  test  it  is  also  incorporated  into  the  listings.  If 
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a program  is  stand-alone  (it  doesn't  need  to  delinked  with 
anything  else)  it  has  no  extra  information.  This  is  also  true  for 
header  files.  However,  if  it  doesn't  contain  amain(  )and  is  meant 
to  delinked  with  something  else,  then  it  has  an  ■P}after  the  file 
name.  If  this  listing  is  meant  to  be  the  main  program  but  needs  to 
be  linked  with  other  components,  there's  a separate  line  that  begins 
with //'ll.  )and  continues  with  all  the  files  that  need  to  delinked 
(without  extensions,  si  nee  those  can  vary  from  platform  to 
platform). 

You  can  find  examples  throughout  the  book. 

If  afileshould  be  extracted  but  the  begin-  and  end-tags  should  not 
be  i ncl  uded  i n the  extracted  fi  I e (for  exampi e,  if  it's  a fi  le  of  test 
data)  then  thebegin-tag  is  immediately  followed  by  a '!'. 


Parentheses,  braces,  and  indentation 

Y ou  may  noti  ce  the  formatti  ng  styl  e i n thi  s book  i s d ifferent  from 
many  traditional  C styles.  Of  course,  everyone  thinks  their  own 
style  is  the  most  rational.  However,  the  style  used  here  has  a simple 
logic  behind  it,  which  will  be  presented  here  mixed  in  with  ideas  on 
why  some  of  the  other  styles  developed. 

The  formatting  style  is  motivated  by  one  thing:  presentation,  both 
in  print  and  in  live  seminars.  You  may  feel  your  needs  are  different 
because  you  don't  make  a lot  of  presentations.  However,  working 
codeisread  much  more  than  it  is  written,  and  soitshould  be  easy 
for  the  reader  to  perceive.  M y two  most  important  criteria  are 
"scannability"  (how  easy  it  is  for  the  reader  to  grasp  the  meaning  of 
a single  line)  and  thenumber  of  lines  that  can  fit  on  a page.  This 
latter  may  sound  funny,  but  when  you  are  giving  a live 
presentation,  it's  very  distracting  for  the  audience  if  the  presenter 
must  shuffle  back  and  forth  between  slides,  and  a few  wasted  lines 
can  cause  this. 
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Everyone  seenns  to  agree  that  code  inside  braces  should  be 
indented.  What  people  don't  agree  on  - and  the  pi  ace  where  there's 
the  most  inconsistency  within  formatting  styles-  isthis:  Where 
does  the  opening  brace  go?  This  one  question,  I think,  is  what 
causes  such  variations  among  coding  styles  (For  an  enumeration  of 
coding  styles,  see  C++ Programming  Guidelines,  by  Tom  Plum  and 
Dan  Saks,  Plum  Hall  1991.)  I'll  try  to  convince  you  that  many  of 
today'scoding  styles  come  from  pre-Standard  C constraints  (before 
function  prototypes)  and  are  thus  inappropriate  now. 

First,  my  answer  to  that  key  question:  the  opening  brace  should 
always  go  on  the  sameline  as  the"precursor"  (by  which  I mean 
"whatever  the  body  is  about:  a class,  function,  object  definition,  if 
statement,  etc").  This  is  a single,  consistent  rule  I apply  to  all  of  the 
code  I write,  and  it  makes  formatti  ng  much  simpler.  It  makes  the 
"scannability"  easier-  when  you  look  at  this  line: 

int  func  (int  a) ; 

you  know,  by  the  semi  col  on  at  the  end  of  theline,  that  this  isa 
declaration  and  it  goes  no  further,  but  when  you  seethe  line: 

int  func (int  a)  { 

you  immediately  know  it's  a definition  because  the  line  finishes 
with  an  opening  brace,  not  a semicolon.  By  using  this  approach, 
there's  no  difference  in  where  you  place  the  opening  parenthesis 
for  a multi-linedefinition: 

int  func (int  a)  { 
int  b = a + 1; 
return  b * 2; 

} 

and  for  a single-line  definition  that  is  often  used  for  inlines: 

int  func (int  a)  { return  (a  + 1)  * 2;  } 

Similarly,  for  a cl  ass: 
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class  Thing; 


is  a class  name  declaration,  and 

class  Thing  { 

i s a cl  ass  defi  niti  on.  You  can  tel  I by  I ooki  ng  at  the  si  ngl  e I i ne  i n al  I 
cases  whether  it's  a declaration  or  definition.  And  of  course, 
putting  the  opening  brace  on  the  same  line,  instead  of  a line  by 
itself,  allows  you  to  fit  more  lines  on  a page. 

So  why  do  we  have  so  many  other  styles?  In  particular,  you'll 
notice  that  most  people  create  cl  asses  foil  owing  the  style  above 
(which  Stroustrup  usesin  all  editions  of  his  book  TheC++ 
Programming  Languagefrom  Addison-Wesley)  but  create  function 
definitions  by  putting  the  opening  brace  on  asinglelineby  itself 
(which  also  engenders  many  different  indentation  styles). 
Stroustrup  does  this  except  for  short  inline  functions.  With  the 
approach  I describe  here,  everything  is  consistent  - you  name 
whatever  it  is  (class;  function,  enum,  etc.)  and  on  that  same  line 
you  put  the  opening  brace  to  indicatethatthe  body  for  thisthing  is 
about  to  fol  I ow.  A I so,  the  openi  ng  brace  i s the  same  for  short 
inlines  and  ordinary  function  definitions. 

I assert  that  the  style  of  function  definition  used  by  many  folks 
comes  from  pre-function-prototyping  C,  in  which  you  didn't 
declarethe  arguments  inside  the  parentheses,  but  instead  between 
the  closing  parenthesis  and  the  opening  curly  brace  (this  shows  C's 
assembly-language  roots): 

void  bar ( ) 
int  X ; 
float  y; 

{ 

/*  body  here  */ 

} 

Here,  it  would  bequite  ungainly  to  put  the  opening  brace  on  the 
same  line,  so  no  one  did  it.  However,  they  did  make  various 
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decisionsabout  whether  the  braces  should  be  indented  with  the 
body  of  the  code  or  whether  they  should  be  at  the  level  of  the 
"precursor."  Thus,  we  got  many  different  formatting  styles. 

There  are  other  arguments  for  placing  the  brace  on  the  line 
immediately  foil  owing  the  declaration  (of  a class,  struct,  function, 
etc).  The  foil  owing  came  from  a reader,  and  is  presented  here  so 
you  know  what  the  issues  are: 

Experienced  'vi'  (vim)  users  know  that  typing  the']'  key  twice 
will  taketheuserto  the  next  occurrence  of '{  (or  '\)  in  column 
O.Thisfeature  is  extremely  useful  in  navigating  code  (jumping 
to  the  next  function  or  class  definition).  [My  comment:  when  I 
was  initially  working  under  Unix,  GNU  Emacs  wasjust 
appearing  and  I became  enmeshed  in  that.  Asa  result,  'vi'  has 
never  made  sense  to  me,  and  thus  I do  not  think  in  terms  of 
"column  Olocations."  However,  there  is  a fair  contingent  of 'vi' 
users  out  there,  and  they  are  affected  by  this  issue.] 

PI aci  ng  the ' { on  the  next  I i ne  el  i mi  nates  some  confusi  ng  code 
in  complex  conditionals,  aiding  in  thescannability.  Example: 

if (condl 

&&  cond2 
&&  condS)  { 
statement ; 

} 

The  above  [asserts  the  reader]  has  poor  scannabi  I ity.  H owever, 

if  (condl 
&&  cond2 
&&  condS) 

{ 

statement ; 

} 

breaks  up  the 'if  from  the  body,  resulting  in  better  readability. 
[Your  opinions  on  whether  this  is  true  will  vary  depending  on 
what  you're  used  to.] 


792 


Thinking  in  C+  + 


www.BruceEckel.com 


Finally,  it's  much  easierto  visually  align  braces  when  they  are 
aligned  in  thesamecolumn.  They  visually  "stick  out"  much 
better.  [End  of  reader  comment] 

The  issue  of  whereto  put  the  opening  curly  brace  is  probably  the 
most  discordant  issue.  I've  learned  to  scan  both  forms,  and  in  the 
end  it  comes  down  to  what  you've  grown  comfortable  with. 
However,  I note  that  the  official  Java  coding  standard  (found  on 
Sun's  Java  Website)  is  effectively  the  same  as  the  one  I present  here 
- since  morefolksare  beginning  to  program  in  both  languages,  the 
consistency  between  coding  styles  may  be  helpful. 

The  approach  I use  removes  all  the  exceptions  and  special  cases, 
and  logically  produces  a si nglestyleof  indentation  as  well.  Even 
within  a function  body,  the  consistency  holds,  as  in: 

for(int  i = 0;  i < 100;  i++)  { 

cout  <<  i <<  endl; 
cout  <<  X * i <<  endl; 

} 

The  Style  is  easy  to  teach  and  to  remember  - you  use  a single, 
consi  stent  ru  I e for  al  I you  r formatti  ng,  not  one  for  cl  asses,  two  for 
functions  (one-line  inlines  vs.  multi-line),  and  possibly  others  for 
for  loops,  if  statements,  etc.  The  consistency  alone,  I think,  makes  it 
worthy  of  consideration.  Above  all,  C-H-isa  newer  language  than 
C,  and  although  we  must  make  many  concessionstoC,  we 
shouldn't  be  carrying  too  many  artifacts  with  us  that  cause 
problems  in  the  future.  Small  problems  multiplied  by  many  lines  of 
code  become  big  problems.  For  a thorough  examination  of  the 
subject,  albeit  in  C,  see  C Style:  Standards  and  Guidelines,  by  David 
Straker  (Prentice-Hall  1992). 

The  other  constraint  I must  work  under  isthelinewidth,  si  nee  the 
book  has  a limitation  of  50  characters.  What  happens  when 
something  istoo  long  to  fit  on  one  line?  Well,  again  I strive  to  have 
a consistent  policy  for  the  way  lines  are  broken  up,  so  they  can  be 
easily  viewed.  As  long  as  something  is  part  of  a single  definition. 
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argument  list,  etc,  continuation  lines  should  be  indented  one  level 
in  from  the  beginning  of  that  definition,  argument  list,  etc. 


I dentifier  names 

Thosefamiliar  with  Java  will  noticethatl  have  switched  to  using 
thestandard  Java  style  for  all  identifier  names.  However,  I cannot 
be  completely  consistent  here  because  identifiers  in  the  Standard  C 
and  C++ libraries  do  not  follow  thisstyle. 

The  sty  I e i s qu  ite  strai  ghtforward . The  f i rst  I etter  of  an  i dentif  i er  i s 
only  capitalized  if  that  identifier  isa  class.  If  it  isafunction  or 
variable,  then  the  first  letter  is  lowercase.  The  rest  of  the  identifier 
consists  of  one  or  more  words,  run  together  but  distinguished  by 
capitalizing  each  word.  So  a cl  ass  looks  I ike  this: 

I class  FrenchVanilla  : public  IceCream  { 

an  object  identifier  looks  I ike  this: 

I FrenchVanilla  mylceCreamCone ( 3 ) ; 

and  afunction  looks likethis: 

I void  eatlceCreamCone ( ) ; 

(for  either  a member  function  or  a regular  function). 

The  one  exception  is  for  compi  le-ti  me  constants  (constor  #defin^, 
in  which  all  of  the  letters  in  the  identifier  are  uppercase. 

Thevalueof  the  style  is  that  capitalization  has  meaning -you  can 
see  from  the  first  letter  whether  you're  talking  about  a class  or  an 
object/  method.  This  is  especially  useful  when  staticclass  members 
are  accessed. 
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Order  of  header  inclusion 

Headers  are  included  in  order  from  "the  most  specific  to  the  most 
general."  That  is,  any  header  files  in  the  local  directory  are  included 
first,  then  any  of  my  own  "tool"  headers,  such  as  require.h  then 
any  third-party  library  headers,  then  the  Standard  C-H-Library 
headers,  and  finally  the  C library  headers. 

Thejustification  forthiscomesfromjohn  Lakosin  Large-Scale  C++ 
Software  Design  (Addison-Wesley,  1996): 

Latent  usage  errors  can  be  avoided  by  ensuring  that  the.h  file  of  a 
component  parses  by  itself  - without  extern  ally- provided  declarations 
or  definitions...  Including  the  .h  file  as  the  very  first  line  of  the. c file 
ensures  that  no  critical  piece  of  information  intrinsic  to  the  physical 
interface  of  the  component  is  missing  from  the.h  file  (or,  if  there  is, 
that  you  will  find  out  about  it  as  soon  as  you  try  to  compile  the  .c  file). 

If  the  order  of  header  inclusion  goes  "from  most  specific  to  most 
general,"  then  it's  more  likely  that  if  your  header  doesn't  parse  by 
itself,  you'll  find  out  about  it  sooner  and  prevent  annoyances  down 
the  road. 


I nclude  guards  on  header  files 

/nc/udeguards  are  always  used  inside  header  files  to  prevent 
multiple  inclusion  of  a header  fileduring  the  compilation  of  a 
si  ngl  e xpp  f i I e.  The  i ncl  ude  guards  are  i mpl emented  usi  ng  a 
preprocessor  #defineand  checking  to  see  that  a name  hasn't 
al  ready  been  defi  ned . The  name  used  for  the  guard  i s based  on  the 
name  of  the  header  file,  with  all  lettersof  the  file  name  uppercase 
and  replacing  the'.'  with  an  underscore.  For  example: 

//  IncludeGuard . h 
#ifndef  INCLUDEGUARD_H 
#define  INCLUDEGUARD_H 
//  Body  of  header  file  here. . . 

#endif  //  INCLUDEGUARD_H 
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The  identifier  on  theiast  iineisinciuded  for  darity.  Aithough  some 
preprocessors  ignored  any  characters  after  an  #endif,  that  isn't 
standard  behavior  and  so  the  identifier  is  commented. 


Use  of  namespaces 

in  header  fiies,  any  "poiiution"  of  the  namespace  i n which  the 
header  is  inciuded  must  bescrupuiousiy  avoided.  That  is,  if  you 
changethe  namespace  outside  of  a function  orciass,  you  wiii  cause 
that  change  to  occur  for  any  fiiethat  inciudesyour  header, 
resuiting  in  aii  kinds  of  probiems.  No  usingdeciarationsof  any 
kind  are  aii  owed  outside  of  function  definitions,  and  no  giobai 
usingdirectivesareaiiowed  in  header  fiies. 

in  cpp  fiies,  any  giobai  using  directives  wiii  oniy  affect  that  fiie, 
and  so  in  this  book  they  aregeneraiiy  used  to  produce  moreeasiiy- 
readabiecode,  especiaiiy  in  smaii  programs. 

Use  of  require(  ) and  assure(  ) 

Therequire(  )and  assure(  )fu notions  defined  in  require.h are  used 
consistentiy  throughout  most  of  the  book,  so  that  they  may 
properiy  report  probiems.  if  you  are famiiiar  with  the  concepts  of 
preconditions an6  postcond/t/ons (introduced  by  Bertrand  Meyer)  you 
wiii  recognize  that  the  use  of  require(  )and  assure(  )moreor  iess 
provide  preconditions  (usuaiiy)  and  postconditions  (occasionaiiy). 
Thus,  at  the  beginning  of  afunction,  before  any  of  the  "core"  of  the 
function  is  executed,  the  preconditions  are  checked  to  make  sure 
everything  is  proper  and  that  aii  of  the  necessary  conditions  are 
correct. Then  the"core"  of  thefunction  isexecuted,  and  sometimes 
some  postconditions  are  checked  to  make  sure  that  the  new  state  of 
thedata  is  within  defined  parameters.  You'ii  notice  that  the 
postcondition  checks  are  rare  in  this  book,  and  assure(  )is 
primariiy  used  to  make  surethat  fiies  were  opened  successfuiiy. 
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B:  Programming  Guidelines 

This  appendix  is  a coiiection  of  suggestions  for  C++ 
programming.  They've  been  assembied  over  the  course 
of  my  teaching  and  programming  experience  and 
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al so  from  the  i nsi ghts  of  fri ends  i ncl ud i ng  Dan  Saks  (co-author  with 
Tom  Plum  of  C++  Programming  Guidelines,  Plum  Hall,  1991),  Scott 
Meyers  (author  of  Effect/Ve  C ++,  2^^  edition.  Add  I son- Wesley,  1998), 
and  Rob  M urray  (author  of  C++  Strategies  & Tactics,  Addison-Wesley, 
1993).  A Iso,  many  of  the  ti  ps  are  summarized  from  the  pages  of 
Thinking  in  C++. 

1.  First  make  it  work,  then  make  itfast.  This  is  true  even  if  you 
are  certain  that  a piece  of  code  is  really  important  and  that  it 
will  bea  principal  bottleneck  in  your  system.  Don't  do  it.  Get 
the  system  going  first  with  as  simple  a design  as  possible. 
Then  if  it  isn't  going  fast  enough,  profile  it.  You'll  almost 
alwaysdiscover  that  "your"  bottleneck  isn't  the  problem. 
Save  your  ti  me  for  the  real  ly  important  stuff. 

2.  Elegance  always  pays  off.  It's  not  a frivolous  pursuit.  Not 
only  does  it  give  you  a program  that's  easier  to  build  and 
debug,  but  it's  also  easier  to  understand  and  maintain,  and 
that's  where  the  fi  nanci  al  val  ue  I i es.  Thi  s poi  nt  can  take  some 
experience  to  believe,  because  it  can  seem  that  while  you're 
making  a piece  of  code  elegant,  you're  not  being  productive. 
The  productivity  comes  when  the  code  seamlessly  integrates 
into  your  system,  and  even  more  so  when  the  code  or  system 
is  modified. 

3.  Remember  the  "divide  and  conquer"  principle.  Ifthe 
problem  you're  looking  at  is  too  confusing,  try  to  imagine 
what  the  basic  operation  of  the  program  would  be,  given  the 
exi  stence  of  a magi  c "piece"  that  hand  I es  the  hard  parts.  That 
"piece"  isan  object-  write  the  code  that  uses  the  object,  then 
look  at  the  object  and  encapsulate  its  hard  parts  into  other 
objects,  etc. 

4.  Don't  automatically  rewrite  all  your  existing  C code  in  C-H- 
unlessyou  need  to  significantly  change  its  functionality  (that 
is,  don't  fix  it  if  it  isn't  broken).  Recompiling  C in  C-H-isa 
valuable  activity  because  it  may  reveal  hidden  bugs. 
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However,  taking  C codethat  works  fine  and  rewriting  it  in 
C++ may  not  be  the  best  use  of  your  time,  uniesstheC++ 
versi  on  wi  i i provi  de  a i ot  of  opportu niti es  for  reuse  as  a ci  ass. 

5.  If  you  do  have  a large  body  of  C codethat  needs  changing, 
first  isolatethepartsof  the  code  that  will  not  be  modified, 
possibly  wrapping  those  functions  in  an  "API  class"  as  static 
member  functions.  Then  focus  on  the  code  that  will  be 
changed,  refactori  ng  it  i nto  cl  asses  to  faci  I itate  easy 
modifications  as  your  maintenance  proceeds. 

6.  Separate  the  class  creator  from  the  class  user  {client 
programmer).  The  cl  ass  user  is  the  "customer"  and  doesn't 
need  or  want  to  know  what's  going  on  behind  the  scenes  of 
the  cl  ass.  The  cl  ass  creator  must  be  the  expert  in  class  design 
and  writethe  class  so  that  it  can  be  used  by  the  most  novice 
programmer  possible,  yet  still  work  robustly  in  the 
application.  Library  use  will  be  easy  only  if  it's  transparent. 

7.  When  you  create  a class,  make  your  names  as  clear  as 
possible.  Your  goal  should  be  to  make  the  client 
programmer's  interface  conceptually  simple.  Attempt  to 
make  your  names  so  clear  that  comments  are  unnecessary.  To 
this  end,  use  function  overloading  and  default  arguments  to 
create  an  intuitive,  easy-to-use  interface. 

8.  Access  control  allowsyou  (the  class  creator)  to  change  as 
much  as  possi  bl  e i n the  f utu re  w i thout  d amagi  ng  cl  i ent  cod e 
in  which  the  class  is  used.  In  this  light,  keep  everything  as 
privateas  possible,  and  makeonly  the  cl  ass  interface  public 
always  using  functions  rather  than  data.  Make  data  public 
only  when  forced.  If  class  users  don't  need  to  access  a 
function,  make  it  private  If  a part  of  your  class  must  be 
exposed  to  inheritors  as  protected  provide  a function 

i nterface  rather  than  expose  the  actual  data.  I n this  way, 
implementation  changeswill  have  minimal  impact  on 
derived  classes. 
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9.  Don'tfall  into  analysis  paralysis.  Therearesomethingsthat 
you  don't  learn  until  you  start  coding  and  get  some  kind  of 
system  working.  C++ has  built-in  firewalls;  let  them  work  for 
you.  Your  mistakes  in  a class  or  set  of  classes  won't  destroy 
the  integrity  of  the  whole  system. 

10.  Your  analysis  and  design  must  produce,  at  minimum,  the 
classes  in  your  system,  their  public  interfaces,  and  their 
relationships  to  other  classes,  especially  base  cl  asses.  If  your 
design  methodology  produces  more  than  that,  ask  yourself  if 
all  the  pieces  produced  by  that  methodology  have  value  over 
the  lifetime  of  the  program.  Ifthey  donot,  maintaining  them 
will  cost  you.  Members  of  development  teams  tend  not  to 
maintain  anything  that  does  not  contribute  to  their 
productivity;  this  is  a fact  of  life  that  many  design  methods 
don't  account  for. 

11.  Writethetest  code  first  (before  you  write  the  class),  and  keep 
itwiththeci  ass.  A u to  mate  therunningofyour  tests  t h rou  g h 
a makefi  I e or  si  mi  I ar  tool . Thi  s way,  any  changes  can  be 
automatically  verified  by  running  the  test  code,  and  you'll 
immediately  discover  errors.  Because  you  know  that  you 
have  the  safety  net  of  your  test  framework,  you  will  beholder 
about  making  sweeping  changes  when  you  discover  the 
need.  Remember  that  the  greatest  i mprovements  in 
languages  come  from  the  bui  It-i  n testi  ng  that  type  check!  ng, 
exception  handling,  etc,  provide,  but  those  features  take  you 
only  so  far.  You  must  go  the  rest  of  the  way  in  creating  a 
robust  system  by  fi  1 1 i ng  i n the  tests  that  verify  featu  res  that 
are  specific  to  your  class  or  program. 

12.  Writethetest  code  first  (before  you  write  the  cl  ass)  in  order 
to  verify  that  your  class  design  is  complete.  If  you  can't  write 
test  code,  you  don't  know  whatyour  cl  ass  looks  like.  In 

add  iti  on,  the  act  of  writ!  ng  the  test  code  w i 1 1 often  fl  ush  out 
add  iti  onal  featu  res  or  constrai  nts  that  you  need  i n the  cl  ass  - 
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these  features  or  constraints  don't  always  appear  during 
analysis  and  design. 

13.  Rennennber  a fundamental  rule  of  software  engineer!  ng^: /\// 
software  design  problems  can  be  simplified  by  introducing  an  extra 
level  of  conceptual  indirection.  This  one  idea  isthe  basis  of 
abstraction,  the  pri  mary  feature  of  object-oriented 
programming. 

14.  M ake  cl  asses  as  atomi  c as  possi  bl  e;  that  i s,  gi  ve  each  cl  ass  a 
single,  clear  purpose.  If  your  classes  or  your  system  design 
grows  too  complicated,  break  complex  classes  into  simpler 
ones.  The  most  obvious  indicator  of  this  is  sheer  size:  if  a 
class  is  big,  chances  are  it's  doing  too  much  and  should  be 
broken  up. 

15.  Watch  for  long  member  function  definitions.  A function  that 
is  long  and  complicated  is  difficult  and  expensiveto 
maintain,  and  is  probably  trying  to  do  too  much  all  by  itself. 
If  you  see  such  a function,  it  indicates  that,  at  the  least,  it 
should  be  broken  up  into  multi  pie  functions.  It  may  also 
suggest  the  creation  of  a new  class. 

16.  Watch  for  long  argument  lists.  Function  cal  Is  then  become 
difficult  to  write,  read  and  maintain.  Instead,  try  to  move  the 
member  function  to  a class  where  it  is  (more)  appropriate, 
and/  or  pass  objects  in  as  arguments. 

17.  Don't  repeat  yourself.  If  a pieceof  code  is  recurring  in  many 
functionsin  derived  classes,  put  that  code  into  a single 
function  in  the  base  cl  ass  and  call  it  from  the  derived-class 
functions.  Not  only  do  you  save  code  space,  you  providefor 
easy  propagation  of  changes.  You  can  use  an  inline  function 
for  efficiency.  Sometimes  the  discovery  of  this  common  code 
will  add  valuablefunctionality  toyour  interface. 


^ Explained  to  me  by  Andrew  Koenig. 
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18.  Watch  for  switch  statements  or  chained  if-elseclauses.  This 
istypicaiiy  an  indicator  of  type-check  coding,  which  means  you 
are  choosing  what  codeto  execute  based  on  some  ki  nd  of 
type  information  (the exact  type  may  not  be  obvious  at  first). 
You  can  usuaiiy  repiace  this  kind  of  code  with  inheritance 
and  poiymorphism;  a poiymorphic function  caii  wiii  perform 
the  type  checking  for  you,  and  aiiow  for  more  reiiabieand 
easier  extensibiiity. 

19.  From  a design  standpoint,  iook  for  and  separate  things  that 
change  from  thi  ngs  that  stay  the  same.  That  is,  search  for  the 
eiementsin  a system  that  you  might  want  to  change  without 
forcing  a redesign,  then  encapsui  ate  those  dements  in 
dasses.  You  can  iearn  significantiy  more  about  this  concept  in 
the  Design  Patterns  chapter  in  Voiume2of  this  book, 
avaiiabieat  www.BruceEckel.com. 

20.  Watch  out  for  variance.  Two  semanticaiiy  different  objects 
may  haveidenticai  actions,  or  respond biiities,  and  there  is  a 
naturai  temptation  to  try  to  make  one  a subciass  of  the  other 
just  to  benefit  from  inheritance.  This  iscaiied  variance,  but 
there's  no  reai  justification  to  forcea  superciass/  subciass 
reiationship  where  it  doesn't  exist.  A better  soiuti on  is  to 
create  a gen erai  baseciassthat  produces  an  interface  for  both 
as  derived  dasses-  it  requires  a bit  more  space,  but  you  stiii 
benefit  from  inheritance  and  wiii  probabiy  make  an 

i mportant  d i scovery  about  the  d esi  gn . 

21.  Watch  outfor  iimitation  during  inheritance. Thedearest 
designs  add  new  capabiiities  to  inherited  ones.  A suspicious 
design  removes  oid  capabiiities  during  inheritance  without 
adding  new  ones.  But  ruiesaremadeto  be  broken,  and  if  you 
are  working  from  an  oid  dass  iibrary,  it  may  be  more 
efficient  to  restrict  an  existing  dass  in  its  subciass  than  it 
wouid  be  to  restructurethe  hierarchy  so  your  new  dass  fits 
in  whereitshouid,  above  the  oid  dass. 
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22.  Don't  ©(tend  fundamental  functionality  by  subclassing.  If  an 
interface  element  is  essential  to  a class  it  should  be  in  the  base 
class,  not  added  during  derivation.  If  you're  adding  member 
functions  by  inheriting,  perhaps  you  should  rethink  the 
design. 

2 3 . Less  i s more.  Start  w ith  a mi  ni  mal  i nterface  to  a cl  ass,  as 
small  and  simple  as  you  need  to  solvethe  problem  at  hand, 
but  don't  try  to  antici  pate  al  I the  ways  that  your  class  might 
beused.  Asthe  class  is  used,  you'll  discover  ways  you  must 
expand  the  interface.  However,  onceaclassisin  use  you 
cannot  shrink  the  interface  without  disturbing  client  code.  If 
you  need  to  add  more  functions,  that's  fine;  it  won't  disturb 
code,  other  than  forcing  recompiles.  But  even  if  new  member 
functions  replace  the  functionality  of  old  ones,  leave  the 
existing  interface  alone  (you  can  combine  the  functionality  in 
theunderlying  implementation  if  you  want).  If  you  need  to 
expand  the  interface  of  an  existing  function  by  adding  more 
arguments,  leave  the  existing  arguments  in  their  current 
order,  and  put  default  values  on  all  of  the  new  arguments; 
this  way  you  won't  disturb  any  existing  cal  Is  to  that  function. 

24.  Read  your  cl  asses  aloud  to  make  sure  they're  logical, 
referring  to  the  relationship  between  a base  cl  ass  and  derived 
class  as  "is-a"  and  member  objects  as  "has-a." 

25.  When  deciding  between  inheritance  and  composition,  ask  if 
you  need  to  upcast  to  the  base  type.  If  not,  prefer 
composition  (member  objects)  to  inheritance.  This  can 
eliminate  the  perceived  need  for  multiple  inheritance.  If  you 
inherit,  users  will  think  they  are  supposed  to  upcast. 

26.  Sometimes  you  need  to  inherit  in  order  to  access  protected 
members  of  the  base  class.  This  can  lead  to  a perceived  need 
for  multiple  inheritance.  If  you  don't  need  to  upcast,  first 
derive  a new  class  to  perform  the  protected  access.  Then 
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make  that  new  cl  ass  a member  object  i nsi  de  any  cl  ass  that 
needs  to  use  it,  rather  than  I nheriti  ng. 

27.  Typically,  a baseclass  will  beused  primarily  to  create  an 
interface  to  classes  derived  from  it.  Thus,  when  you  create  a 
base  class,  default  to  maki  ng  the  member  functions  pure 
virtual.  The  destructor  can  also  be  pure  virtual  (to  force 
inheritors  to  explicitly  override  it),  but  remember  to  give  the 
destructor  a function  body,  because  all  destructors  in  a 
hierarchy  are  always  called. 

28.  When  you  put  a virtual  function  in  a class,  make  all  functions 
in  that  cl  ass  virtual,  and  put  in  a virtual  destructor.  This 
approach  prevents  surprises  in  the  behavior  of  the  interface. 
Only  start  removing  the  virtual  keyword  when  you're  tuning 
for  efficiency  and  your  profiler  has  pointed  you  in  this 
direction. 

29.  Use  data  members  for  variation  in  value  and  virtual 
functions  for  variation  in  behavior.  That  is,  if  you  find  a class 
that  uses  state  variables  along  with  member  functions  that 
switch  behavior  based  on  those  variables,  you  should 
probably  redesign  itto  express  the  differences  in  behavior 
within  subclasses  and  overridden  virtual  functions. 

30.  If  you  must  do  something  nonportable,  make  an  abstraction 
for  that  service  and  localize  it  withi  n a class.  This  extra  level 
of  indirection  prevents  the  non-portability  from  being 
distributed  throughout  your  program. 

31.  Avoid  multiple  inheritance.  It's  for  getting  you  out  of  bad 
situations,  especially  repairing  class  interfaces  in  which  you 
don't  havecontrol  of  the  broken  class  (see  Volume  2).  You 
should  bean  experienced  programmer  before  designing 
mu  Iti  pi  e i nheri  tance  i nto  you  r system. 

32.  Don't  use  private!  nheritance.  Although  it's  in  the  language 
and  seems  to  have  occasional  functionality,  it  introduces 
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significant  ambiguities  when  combined  with  run-time  type 
identification.  Create  a private  member  object  i nstead  of 
using  private  inheritance. 

33.  If  two  cl  asses  are  associated  with  each  other  in  some 
functional  way  (such  as  containers  and  iterators),  try  to  make 
one  a public  nested  friend  class  of  the  other,  as  the  Standard 
C-H-Library  does  with  iterators  inside  containers  (examples 
of  this  are  shown  in  the  latter  part  of  Chapter  16).  This  not 
only  emphasizes  the  association  between  the  cl  asses,  but  it 
allows  the  cl  ass  name  to  be  reused  by  nesting  it  within 
another  class.  The  Standard  C-H-Library  does  this  by 
defining  a nested  iteratorcl  ass  inside  each  container  class, 
thereby  providing  the  containers  with  a common  interface. 
The  other  reason  you'll  want  to  nest  a class  is  as  part  of  the 
privateimplementation.  Here,  nesting  is  beneficial  for 
implementation  hiding  rather  than  the  cl  ass  association  and 
prevention  of  namespace  pollution  noted  above. 

34.  Operator  overloading  is  only  "syntactic  sugar:"  a different 
way  to  makea  function  call.  If  overloading  an  operator 
doesn't  make  the  cl  ass  interface  clearer  and  easier  to  use, 
don't  do  it.  Create  only  one  automatic  type  conversion 
operator  for  a class.  In  general,  follow  the  guidelines  and 
format  given  in  Chapter  12  when  overloading  operators. 

35.  Don'tfall  prey  to  premature  optimization.  That  way  lies 
madness.  In  particular,  don't  worry  about  writing  (or 
avoiding)  inlinefunctions,  making  some  functions 
nonvirtual  or  tweaking  code  to  be  efficient  when  you  are 
firstconstructingthesystem.  Your  primary  goal  should  be  to 
prove  the  design,  unless  the  design  requires  a certain 
efficiency. 

36.  Normally,  don't  let  the  compiler  create  the  constructors, 
destructors,  or  the operator=for  you.  Class  designers  should 
always  say  exactly  what  the  cl  ass  should  do  and  keep  the 
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class  entirely  under  control.  If  you  don't  want  a copy- 
constructor  or  operator^  declare  them  as  private  Remember 
that  if  you  create  any  constructor,  it  prevents  the  default 
constructor  from  being  synthesized. 

37.  If  your  class  contains  pointers,  you  must  create  the  copy- 
constructor,  operator^  and  destructor  for  the  class  to  work 
properly. 

38.  When  you  write  a copy-constructor  for  a derived  class, 
remember  to  call  the  base-class  copy-constructor  explicitly 
(also  the  member-object  versions).  (See  Chapter  14.)  If  you 
don't,  the  default  constructor  will  be  cal  led  for  the  base  class 
(or  member  object)  and  that  probably  isn't  what  you  want.  To 
call  the  base-class  copy-constructor,  pass  it  the  derived  object 
you're  copying  from: 

Derived (const  Derived&  d)  : Base (d)  { //  ... 

39.  When  you  write  an  assignment  operator  for  a derived  class, 
remember  to  cal  I the  base-class  version  of  the  assignment 
operator  explicitly.  (See  Chapter  14.)  If  you  don't,  then 
nothing  will  happen  (the  same  is  true  for  the  member 
objects).  To  call  the  base-class  assignment  operator,  use  the 
base-class  name  and  scope  resolution: 

Derived&  operator= (const  Derived&  d)  { 

Base: : operator= (d) ; 

40.  If  you  need  to  minimize  recompiles  during  development  of  a 
large  project,  usethe  handle  class/  Cheshire  cat  technique 
demonstrated  in  Chapter  5,  and  remove  it  only  if  runtime 
efficiency  Isa  problem. 

41.  Avoid  the  preprocessor.  Always  useconstfor  value 
substitution  and  inlinesfor  macros. 

42.  Keep  scopes  as  small  as  possibleso  the  visibility  and  lifetime 
of  your  objects  areas  small  as  possible.  This  reduces  the 
chance  of  using  an  object  in  the  wrong  context  and  hiding  a 
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difficult-to-find  bug.  For  ©cample,  suppose  you  havea 
container  and  a piece  of  code  that  iterates  through  it.  If  you 
copy  that  codeto  use  with  a new  container,  you  may 
accidentally  end  up  using  the  size  of  the  old  contai  ner  as  the 
upper  bound  of  the  new  one.  If,  however,  the  old  container  is 
out  of  scope,  the  error  will  be  caught  at  compi le ti me. 

43.  Avoid  global  variables.  Always  strive  to  put  data  inside 
classes.  Global  functions  are  more  likely  to  occur  naturally 
than  global  variables,  although  you  may  later  discover  that  a 
global  function  may  fit  better  as  a static  member  of  a class. 

44.  If  you  need  to  declare  a cl  ass  or  function  from  a library, 
always  do  so  by  including  a header  file.  For  example,  if  you 
want  to  create  a functi  on  to  write  to  an  ostream  never 
deci  are  ostreamyourself  using  an  incomplete  type 
specification  likethis, 

class  ostream; 

This  approach  I eaves  you  r code  vu  I nerabi  e to  changes  I n 
representation.  (For  example,  ostream  could  actually  be  a 
typedef.)  Instead,  always  usethe  header  file: 

#include  <iostream> 

When  creating  your  own  classes,  if  a library  is  big,  provide 
your  users  an  abbreviated  form  of  the  header  file  with 
incomplete  type  specif!  cations  (that  is,  class  name 
declarations)  for  cases  in  which  they  need  to  use  only 
pointers.  (It  can  speed  compilations.) 

45.  When  choosing  the  return  type  of  an  overloaded  operator, 
consider  what  will  happen  if  expressions  are  chained 
together.  Return  a copy  or  reference  to  the  lvalue  (return 
♦this)  so  it  can  be  used  in  a chained  expression  (A  = B = Q. 
When  defining  operator^  remember  x=x 

46.  When  writing  a function,  pass  arguments  by  const  reference 
as  your  first  choice.  As  long  as  you  don't  need  to  modify  the 
object  being  passed,  this  practice  is  best  because  it  has  the 
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simplicity  of  pass-by-value  syntax  but  doesn't  require 
expensive  constructions  and  destructions  to  create  a local 
object,  which  occurs  when  passing  by  value.  Normally  you 
don't  want  to  be  worrying  too  much  about  efficiency  issues 
when  designing  and  building  your  system,  but  this  habit  is  a 
surewin. 

47.  Be  aware  of  temporaries.  When  tuning  for  performance, 
watch  out  for  temporary  creation,  especially  with  operator 
overloading.  If  your  constructors  and  destructors  are 
complicated,  the  cost  of  creating  and  destroying  temporaries 
can  be  high.  When  returning  a value  from  a function,  always 
try  to  build  the  object  "in  place"  with  a constructor  call  in  the 
return  statement: 

return  MyType ( i , j ) ; 
rather  than 
MyType  x(i,  j) ; 
return  x; 

The  former  return  statement  (theso-called  return-value 
optimization)  el  i mi  nates  a copy-constructor  call  and  destructor 
call. 

48.  When  creating  constructors,  consider  exceptions.  In  the  best 
case,  the  constructor  won't  do  anyth!  ng  that  throws  an 
exception.  Inthe  next-best  scenario,  the  class  will  be 
composed  and  inherited  from  robust  classes  only,  so  they 
will  automatically  clean  themselves  up  if  an  exception  is 
thrown.  If  you  must  have  naked  pointers,  you  are  responsible 
for  catching  your  own  exceptions  and  then  deallocating  any 
resources  pointed  to  before  you  throw  an  exception  in  your 
constructor.  If  a constructor  must  fail,  the  appropriate  action 
isto  throw  an  exception. 

49.  Do  only  what  is  minimally  necessary  in  your  constructors. 
Not  only  does  this  produce  a lower  overhead  for  constructor 
calls  (many  of  which  may  not  be  under  your  control)  but 
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your  constructors  are  then  I ess  likely  to  throw  exceptions  or 
cause  problems. 

50.  The  responsibility  of  the  destructor  isto  release  resources 
allocated  during  the  lifetime  of  the  object,  not  just  during 
construction. 

51.  Useexception  hierarchies,  preferably  derived  from  the 
Standard  C++exception  hierarchy  and  nested  as  public 
classes  withi  n the  class  that  throws  the  exceptions.  The 
person  catching  the  exceptions  can  then  catch  the  specific 
types  of  exceptions,  fol  lowed  by  the  base  type.  If  you  add 
new  derived  exceptions,  existing  client  code  will  still  catch 
the  exception  through  the  base  type. 

52.  Throw  exceptions  by  value  and  catch  exceptions  by 
reference.  Let  the  exception-handling  mechanism  handle 
memory  management.  If  you  throw  pointers  to  exception 
objects  that  have  been  created  on  the  heap,  the  catcher  must 
know  to  destroy  the  exception,  which  isbad  coupling.  Ifyou 
catch  exceptions  by  value,  you  cause  extra  constructions  and 
destructions;  worse,  the  derived  portions  of  your  exception 
objects  may  be  sliced  during  upcasting  by  value. 

53.  Don't  write  your  own  class  templates  unless  you  must.  Look 
fi  rst  in  the  Standard  C-H-  Library,  then  to  vendors  who  create 
special -purpose tools.  Become  proficient  with  their  use  and 
you'll  greatly  increase  your  productivity. 

54.  When  creating  templates,  watch  for  codethat  does  not 
depend  on  type  and  put  that  code  in  a non-template  base 
class  to  prevent  needless  code  bloat.  Using  inheritance  or 
composition,  you  can  create  templates  in  which  the  bulk  of 
the  code  they  contain  is  type-dependent  and  therefore 
essential. 

55.  Don't  usethe<cstdio>functions,  such  asprintf( ) Learn  to 
use  i ostreams  i nstead ; they  are  type-safe  and  ty pe-extensi  bl  e. 
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and  significantly  more  powerful.  Your  investment  will  be 
rewarded  regularly.  In  general,  always  use  C++ libraries  in 
preference  to  C 1 1 brari  es. 

56.  Avoid  C'sbuilt-intypes.  They  are  supported  in  C++for 
backward  compatibility,  but  they  are  much  less  robust  than 
C++classes,  so  your  bug-hunting  time  will  increase. 

57.  Whenever  you  use  built-in  types  as  globals  or  automatics, 

don't  define  them  until  you  can  also  initialize  them.  Define 
variables  one  per  line  along  with  their  initialization.  When 
defi  ni  ng  poi  nters,  put  the  next  to  the  type  name.  Y ou  can 

safely  do  this  if  you  define  one  variable  per  line.  This  style 
tends  to  be  less  confusing  for  the  reader. 

58.  Guaranteethat  initialization  occurs  in  all  aspects  of  your 
code.  Perform  all  member  initialization  in  the  constructor 
initializer  list,  even  built-in  types  (using  pseudo-constructor 
calls).  Using  the  constructor  initializer  list  is  often  more 
efficient  when  initializing  subobjects;  otherwise  the  default 
constructor  is  cal  led,  and  you  end  up  calling  other  member 
functions  (probably  operator^  on  top  of  that  i n order  to  get 
the  initialization  you  want. 

59.  Don't  usetheform  MyTypea  = bjto  define  an  object.  This 
one  feature  is  a major  source  of  confusion  because  it  calls  a 
constructor  instead  of  the  operators  For  clarity,  always  be 
specific  and  usetheform  MyType  a(b);nstead.  The  results 
areidentical,  but  other  programmers  won't  be  confused. 

60.  Use  the  explicit  casts  described  in  Chapter  3.  A cast  overrides 
the  normal  typing  system  and  is  a potential  error  spot.  Since 
the  expl  icit  casts  divide  C's  one-cast-does-al  I into  classes  of 
well-marked  casts,  anyone  debugging  and  maintaining  the 
codecan  easilyfind  all  the  places  where  logical  errors  are 
most  likely  to  happen. 
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61.  For  a program  to  be  robust,  each  component  must  be  robust. 
Use  all  the  tools  provided  by  C++:  access  control , exceptions, 
const-correctness,  type  checking,  and  so  on  in  each  cl  ass  you 
create.  That  way  you  can  safely  move  to  the  next  level  of 
abstraction  when  building  your  system. 

62.  Build  in  constcorrectness.  This  allows  the  compiler  to  point 
out  bugs  that  would  otherwise  be  subtle  and  difficult  to  find. 
This  practice  takes  a littledisciplineand  must  be  used 
consistently  throughout  your  classes,  but  it  pays  off. 

63.  Use  compiler  error  checking  to  your  advantage.  Perform  all 
compiles  with  full  warnings,  and  fixyour  codeto  remove  all 
warn!  ngs.  Write  code  that  uti  I izes  the  compi  I e-ti  me  errors 
and  warnings  rather  than  that  which  causes  runtime  errors 
(for  example,  don't  use  variadic  argument  lists,  which  disable 
all  type  checking).  Useassert(  )for  debugging,  but  use 
except!  ons  for  ru  nti  me  errors. 

64.  Prefer  compi  I e-ti  me  errors  to  runti  me  errors.  T ry  to  handle  an 
error  as  close  to  the  point  of  its  occurrence  as  possible.  Prefer 
dealing  with  the  error  at  that  point  to  throwing  an  exception. 
Catch  any  exceptions  in  the  nearest  handler  that  has  enough 
information  to  deal  with  them.  Do  what  you  can  with  the 
exception  at  the  current  level;  if  that  doesn't  solve  the 
problem,  rethrow  the  exception.  (See  Volume  2 for  more 
details.) 

65.  If  you'reusing  exception  specifications  (seeVolume  2 of  this 
book,  down  load  able  from  www.Bruc^ckel.com,  to  learn  about 
exception  handling),  install  your  own  unexpected ( function 
using  set_ un expected (.)Y our  unexpected(  )should  log  the 
error  and  rethrow  the  current  exception.  That  way,  if  an 
existing  function  gets  overridden  and  starts  throwing 
exceptions,  you  will  havea  record  of  the  culprit  and  can 
modify  your  calling  codeto  handle  the  exception. 
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66.  Create  a user-defined  terminate(  Kindicating  a programmer 
error)  to  log  the  error  that  caused  the  exception,  then  release 
system  resources,  and  exit  the  program. 

67.  If  a destructor  calls  any  functions,  those  functions  might 
throw  exceptions.  A destructor  cannot  throw  an  exception 
(thiscan  result  in  acall  toterminate(  )which  indicatesa 
programming  error),  so  any  destructor  that  cal  Is  functions 
must  catch  and  manage  its  own  exceptions. 

68.  Don't  create  your  own  "decorated"  private  data  member 
names  (prepending  underscores,  Hungarian  notation,  etc.), 
unless  you  have  a lot  of  pre-existing  global  values;  otherwise, 
let  classes  and  namespaces  do  the  name  scopi  ng  for  you. 

69.  Watch  for  overloading.  A function  should  not  conditionally 
execute  code  based  on  the  value  of  an  argument,  defaulter 
not.  In  thiscase,  you  should  create  two  or  more  overloaded 
functions  instead. 

70.  Hide  your  pointers  inside  container  classes.  Bring  them  out 
only  when  you  are  going  to  immediately  perform  operations 
on  them.  Pointers  have  always  been  a major  source  of  bugs. 
When  you  use  new,  try  to  drop  the  resulting  pointer  into  a 
container.  Prefer  that  a container  "own"  its  pointers  so  it's 
responsible  for  cleanup.  Even  better,  wrap  a pointer  insidea 
class;  if  you  still  want  it  to  look  I ike  a pointer,  overload 
operator- >and  operator*  If  you  must  have  a free-standing 
pointer,  always  initialize  it,  preferably  to  an  object  address, 
but  to  zero  if  necessary.  Set  it  to  zero  when  you  delete  it  to 
prevent  accidental  multipledeletions. 

71.  Don't  overload  global  new  and  delete  always  do  this  on  a 
cl  ass- by-class  basis.  Overloading  the  global  versions  affects 
the  entire  client  programmer  project,  something  only  the 
creators  of  a project  should  control.  When  overloading  new 
and  deletefor  classes,  don't  assume  that  you  know  the  size 
of  the  object;  someone  may  be  inheriting  from  you.  Use  the 
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provided  argument.  If  you  do  anything  special,  consider  the 
effect  it  could  have  on  inheritors. 

72.  Prevent  object  slicing.  It  virtually  never  makes  senseto 
upcast  an  object  by  value.  To  prevent  upcasting  by  value,  put 
pure  virtual  functions  in  your  base  cl  ass. 

73.  Sometimessimpleaggregation  doesthejob.  A "passenger 
comfort  system"  on  an  airline  consists  of  disconnected 
elements:  seat,  air  conditioning,  video,  etc,  and  yet  you  need 
to  create  many  of  these  in  a plane.  Do  you  make  private 
members  and  build  awholenew  interface?  No-  inthiscase, 
the  components  are  also  part  of  the  public  interface,  so  you 
should  create  public  member  objects.  Those  objects  have  their 
own  private  implementations,  which  are  still  safe.  Be  aware 
that  simple  aggregation  is  not  a solution  to  be  used  often,  but 
it  does  happen. 
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Thinking  in  C:  Foundations  f or  Java&  Chuck  Allison  (a 

MindView,  Inc.  Senninar-on-CD  ROM,  ©2000,  bound  into  the  back 
of  th i s book  and  al so  aval lableatwww.Bruc^ ckel. com) . Th i s i s a 
cou rse  i ncl  ud  i ng  I ectures  and  si  i des  i n the  fou ndati  ons  of  the  C 
Language  to  prepare  you  to  I earn  Java  or  C++.  This  is  not  an 
exhaustive  course  in  C;  only  the  necessities  for  moving  on  to  the 
other  languages  are  included.  Additional  language-specific  sections 
i ntroduce features  for  the  C-h- or  J ava  programmer-to-be. 
Recommended  prerequisite:  some  experience  with  a high-level 
programming  language,  such  as  Pascal,  BASIC,  Fortran,  or  LISP 
( i t's  possi  bl  e to  stru gg I e th rou g h th e C D w i thout  th i s backg rou  nd , 
but  the  course  isn't  designed  to  bean  introduction  to  the  basics  of 
programming). 


General  C+  + 

The  C++  Programming  Language, >'<3editioa  by  Bjarne 
Stroustrup  (Addison-Wesley  1997).  To  some  degree,  the  goal  of  the 
book  that  you're  currently  holding  isto  allow  you  to  useBjarne's 
book  as  a reference.  Since  his  book  contains  the  description  of  the 
language  by  the  author  of  that  language,  it's  typically  the  place 
where  you'll  goto  resolve  any  uncertainties  about  what  C-H- is  or 
isn't  supposed  to  do.  When  you  get  the  knack  of  the  language  and 
are  ready  to  get  serious,  you'll  need  it. 

C++  Primer,  5*  Edition  by  Stanley  Lippman  and  JoseeLajoie 
(Addison-Wesley  1998).  Not  that  much  of  a primer  anymore;  it's 
evolved  into  a thick  book  filled  with  lots  of  detail,  and  the  one  that  I 
reach  for  along  with  Stroustru  p's  when  trying  to  resolve  an  issue. 
Thinking  in  C++ should  provide  a basis  for  understanding  the  C++ 
Pr/mer  as  wel I as  Stroustrup's  book. 
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C & C++CodeCapsul€jsbyChuckAllison  (Prentice-Hall,  1998). 
This  book  assumes  that  you  already  know  C and  C-H-,  and  covers 
some  of  the  i ssues  that  you  may  be  rusty  on,  or  that  you  may  not 
have  gotten  right  the  first  time.  This  book  fills  in  C gaps  as  well  as 
C-H-gaps. 

The  C ++  StandardThis  is  the  document  that  the  committee 
worked  so  hard  on  for  all  those  years.  This  is  not  free, 
unfortunately.  But  at  least  you  can  buy  the  electronic  form  in  PDF 
for  only  $18  at  www.cssinfo.conn. 

My  own  list  of  books 

Listed  in  order  of  publication.  Not  all  of  these  are  currently 
available. 

Computer  Interfacing  with  Pascai  & (Self-published  viathe 
Eisys  imprint,  1988.  Only  available  via  www.BruceEckd.com).  An 
introduction  to  electronics  from  back  when  CP/ M was  still  king 
and  DOS  was  an  upstart.  I used  high-level  languages  and  often  the 
paral  lei  port  of  the  computer  to  drive  various  electronic  projects. 
Adapted  from  my  columns  in  thefirst  and  best  magazine  I wrote 
for,  M icro  Cornucopia  (To  paraphrase  Larry  O'Brien,  long-time 
editor  of  Software  D &/eiopment  M agazine.  the  best  computer 
magazine  ever  published  - they  even  had  plans  for  building  a robot 
in  a flower  pot!)  Alas,  M icro  C became  lost  long  before  the  I nternet 
appeared.  Creating  this  book  was  an  extremely  satisfying 
publishing  experience. 

Using  C ++(Osborne'  McGraw-Hill  1989).  Oneof  thefirst  books 
out  on  C-H-.  This  is  out  of  print  and  replaced  by  its  second  edition, 
the  renamed  C ++  I nside  & 0 ut 

C++lnside&  OutOsborne^  McGraw-Hill  1993).  As  noted, 
actually  the  2nd  edition  of  Using  C++TheC-H-in  this  book  is 
reasonably  accurate,  but  it's  circa  1992  and  Thinking  in  C++  is 
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intended  to  replace  it.  You  can  find  out  more  about  this  book  and 
download  the  source  code  at  www.BruceEckd.com. 


Thinking  in  C++,  t edition  (Prentice-Hall  1995). 

Biack  Beit  C++,  the  Master's  CoiiectipBruce  Eckel,  editor  (M&T 
Books  1994).  Out  of  print.  A collection  of  chapters  by  various  C-H- 
luminaries  based  on  their  presentations  in  the  C-H- track  at  the 
Software  Development  Conference,  which  I chaired.  The  cover  on 
this  book  stimulated  me  to  gain  control  over  all  future  cover 
designs. 

Thinking  in  Java2nd  edition  (Prentice-Hall,  2000).  Thefirst  edition 
of  this  book  won  the  Software  D evdopment  M agaz/ne  Productivity 
Award  and  thejava  Devdoper's  Journal  Editor's  Choice  A ward  in 
1999.  Down  load  able  from  www.BruceEckd.com. 


Depth  & dark  corners 

These  books  go  more  deeply  into  language  topics,  and  help  you 
avoid  the  typical  pitfalls  inherent  in  developing  C-H- programs. 

Effective  C +-f(2nd  Edition,  Addison-Wesley  1998)  and  M ore 
Effective  C +-f(Addison-Wesley  1996),  by  Scott  M eyers.  The  classic, 
must-have  texts  for  serious  problem-solving  and  codedesign  in 
C -H-.  I 've  tri  ed  to  capture  and  express  many  of  the  concepts  from 
these  books  in  Thinking  in  C++,  but  I don't  fool  myself  in  thinking 
that  I've  succeeded.  If  you  spend  any  serious  time  with  C-H- you'll 
end  up  with  thesebooks.  Alsoavailableon  CD  ROM. 

Ruminations  on  C++by  Andrew  Koenig  and  Barbara  Moo 
(Addison-Wesley,  1996).  Andrew  worked  directly  with  Stroustrup 
on  many  aspects  of  the  C-H- language  and  is  an  extremely  reliable 
authority.  I'veal  so  found  the  incisiveness  of  his  insights  to  be 
refreshing,  and  have  learned  much  from  him,  both  in  print  and  in 
person,  over  the  years. 
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Large-Scale  C++  Software  Desigitoyjohn  Lakos  (Addison- 
Wesley,  1996).  Covers  issues  and  answers  questions  you  will 
encounter  during  the  creation  of  big  projects,  but  often  smaller  ones 
as  well. 

C++  Gema  Stan  Lippman,  editor  (SIGS  publications,  1996).  A 
sel  ecti  on  of  arti  cl  es  from  7/ie  C ++  R qjort. 

The  Design  & Evolution  of  C++)y  BjarneStroustrup  (Addison- 
Wesley  1994).  Insights  from  theinventor  of  C++ about  why  he 
madevarious  design  decisions.  Not  essential,  but  interesting. 


Analysis  & design 

Extreme  Programming  Expiainedy  Kent  Beck  (Addison-Wesley 
2000).  I /oi/ethis  book.  Yes,  I tend  to  take  a radical  approach  to 
things  but  I've  always  felt  that  there  could  be  a much  different, 
much  better  program  development  process,  and  I think  XP  comes 
pretty  darn  close.  The  only  book  that  has  had  a similar  impact  on 
me  was  Peop/el/V  are  (described  below),  which  talks  primarily  about 
the  environment  and  dealing  with  corporate  culture.  Extreme 
Programming  Explained  talks  about  programming,  and  turns  most 
things,  even  recent  "findings,"  on  their  ear.  They  even  go  so  far  as 
to  say  that  pictures  are  OK  as  long  as  you  don't  spend  too  much 
time  on  them  and  arewilling  to  throw  them  away.  (You'll  notice 
that  this  book  does  not  havethe"U  ML  stamp  of  approval"  on  its 
cover.)  I could  see  deciding  whether  to  work  for  a company  based 
solely  on  whether  they  used  XP.  Small  book,  small  chapters, 
effortless  to  read,  exciting  to  think  about.  You  start  imagining 
yourself  working  in  such  an  atmosphere  and  it  brings  visions  of  a 
wholenew  world. 

UM L Distilledby  Martin  Fowler  (2^d  edition,  Addison-Wesley, 
2000).  When  you  fi  rst  encounter  U ML,  itisdaunting  because  there 
are  so  many  diagrams  and  details.  According  to  Fowler,  most  of 
this  stuff  is  unnecessary  so  he  cuts  through  to  the  essentials.  For 
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most  projects,  you  only  need  to  know  a few  diagramming  tools, 
and  Fowler's  goal  is  to  come  up  with  a good  design  rather  than 
worry  about  all  theartifactsof  getting  there.  A nice,  thin,  readable 
book;  the  first  one  you  should  get  if  you  need  to  understand  UML. 

The  Unified  Software  Deveiopment  Proce^  I var Jacobsen, 
Grady  Booch,  and  James  Rumbaugh  (Addison- Wesley  1999).  I went 
in  fully  prepared  to  di  si  ike  this  book.  It  seemed  to  have  all  the 
makings  of  a boring  college  text.  I was  pleasantly  surprised  - only 
pockets  of  the  book  contain  explanations  that  seem  as  if  those 
concepts  aren't  clear  to  the  authors.  The  bulk  of  the  book  is  not  only 
cl  ear,  but  enjoyabi  e.  A nd  best  of  al  I , the  process  makes  a I ot  of 
practical  sense.  It's  not  Extreme  Programming  (and  does  not  have 
the!  r cl  arity  about  test!  ng)  but  it's  al  so  part  of  the  UML  juggernaut 
- even  if  you  can't  getXP  adopted,  most  people  have  cl  imbed 
aboard  the"UM  L is  good"  bandwagon  (regardless  of  their  actual 
level  of  experience  with  it)  and  so  you  can  probably  get  it  adopted. 

I think  this  book  should  be  the  flagship  of  UML,  and  the  one  you 
can  read  after  Fowler's  UML  Distilled  when  you  want  more  detail. 

Before  you  choose  any  method,  it's  helpful  to  gain  perspective  from 
those  who  are  not  try!  ng  to  sel  I one.  It's  easy  to  adopt  a method 
without  really  understanding  what  you  want  out  of  it  or  what  it 
will  dofor  you.  Others  are  using  it,  which  seems  a compel  ling 
reason.  However,  humans  have  a strange  little  psychological  quirk: 
If  they  want  to  bel  I eve  someth!  ng  wi  1 1 sol  ve  the!  r problems,  they'l  I 
try  it.  (This  is  experimentation,  which  is  good.)  But  if  it  doesn't 
solve  their  problems,  they  may  red  ouble  their  efforts  and  begin  to 
announce  loudly  what  a great  thing  they've  discovered.  (This  is 
denial,  which  is  not  good.)  The  assumption  here  may  bethatif  you 
can  get  other  people  in  the  same  boat,  you  won't  be  lonely,  even  if 
it's  going  nowhere  (or  sinking). 

This  is  notto  suggest  that  all  methodologies  go  nowhere,  but  that 
you  should  be  armed  to  the  teeth  with  mental  tools  that  help  you 
stay  in  experimentation  mode("lt's  not  working;  let'stry 
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something  else")  and  out  of  denial  mode  ("No,  that's  not  really  a 
problem.  Everything's  wonderful,  we  don't  need  to  change").  I 
think  thefollowing  books,  read  beforeyou  choose  a method,  will 
provide  you  with  these  tools. 

Software  Creativityby  Robert  Glass  (Prentice-Hall,  1995).  This  is 
the  best  book  I've  seen  that  discusses  perspective  on  the  whole 
methodology  issue.  It's  a collection  of  short  essays  and  papers  that 
Glass  has  written  and  sometimes  acquired  (P.J.  Plauger  is  one 
contributor),  reflecting  his  many  years  of  thinking  and  study  on  the 
subject.  They're  entertaining  and  only  long  enough  to  say  what's 
necessary;  hedoesn't  rambleand  bore  you.  He's  not  just  blowing 
smoke,  either;  there  are  hundreds  of  references  to  other  papers  and 
studies.  All  programmers  and  managers  should  read  this  book 
before  wading  into  the  methodology  mire. 

Software  Runaways:  Monumental  Software  Disasteb^  Robert 
G I ass  (Prenti  ce-H  al  I 1997).  The  great  thi  ng  about  this  book  i s that  it 
bringstotheforefront  what  we  don't  talk  about:  how  many 
projects  not  only  fail,  but  fail  spectacularly.  I find  that  most  of  us 
still  think  "That  can't  happen  to  me"  (or  "That  can't  happen  again”) 
and  I think  this  puts  us  at  a disadvantage.  By  keeping  in  mind  that 
things  can  always  go  wrong,  you're  in  a much  better  position  to 
make  them  go  right. 

Object  Lessoni)y  Tom  Love  (SI GS  Books,  1993).  Another  good 
"perspective"  book. 

Peopleware  by  Tom  Demarco  and  Timothy  Lister  (Dorset  H ouse, 
2nd  edition  1999).  Although  they  have  backgrounds  in  software 
devel opment,  this  book  i s about  projects  and  teams  i n general . But 
the  focus  is  on  the  peop/e  and  their  needs  rather  than  the  technology 
and  itsneeds.  They  talk  about  creating  an  environment  where 
people  will  be  happy  and  productive,  rather  than  deciding  what 
rules  those  people  should  follow  to  be  adequate  components  of  a 
machine.  This  latter  attitude,  I think,  is  the  biggest  contributor  to 
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programmers  smiling  and  nodding  when  XYZ  method  isadopted 
and  then  quietly  doing  whatever  they've  always  done. 

Complexity  by  M . M itchell  Waldrop  (Simon  & Schuster,  1992). 

This  chronicles  the  com!  ng  together  of  a group  of  scientists  from 
different  disciplines  in  Santa  Fe,  New  Mexico,  to  discuss  real 
probi  ems  that  the  i nd  i vi d ual  d i sci  pi  i nes  cou I d n't  sol  ve  (the  stock 
market  in  economics,  the  initial  formation  of  life  in  biology,  why 
people  do  what  they  do  in  sociology,  etc).  By  crossing  physics, 
economics,  chemistry,  math,  computer  science,  sociology,  and 
others,  a multidisciplinary  approach  to  these  problems  is 
developing.  But  more  importantly,  a different  way  of  thinking  about 
these  ultra-complex  problems  is  emerging:  Away  from 
mathematical  determinism  and  the  illusion  that  you  can  write  an 
equation  that  predicts  all  behavior  and  toward  first  observing  and 
looking  for  a pattern  and  trying  to  emu  I ate  that  pattern  by  any 
means  possible.  (The  book  chronicles,  for  example,  the  emergence 
of  genetic  algorithms.)  This  kind  of  thinking,  I believe,  is  useful  as 
we  observe  ways  to  manage  more  and  more  compi  ex  software 
projects. 
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- ■ 156, 163 

- ■ 164 
! ■ 163 
!=■  158 

#,  preprocessor  string! ze  operator  ■ 196 

#lefine-  194,245,335,353 

ifendif  ■ 245,  757 

#ifdef  ■ 194,  245 

#ifndef  ■ 246 

include  - 85 

^ndef  ■ 194 

$<;  in  makefiles  ■ 206 

% ■ 156 

& ■ 134, 164 

&&,  logicai  and  - 158 

Si,  bitwise  and  ■ 159 

&=bitwise-  160 

( ),  overioading  the  function  cail  operator  ■ 
514 

*■  156;  overioaded  operator  ■ 727,  730; 

pointer  dereference  ■ 136 
-,  with  pointers  ■ 192 
with  pointers  ■ 192 
. member  seiection  operator  ■ 237 
...  variabie  argument  list  ■ 114;  varargs  ■ 
243 
/ ■ 156 

;;  ■ 232,  429;  scope  resoiuti on  operator,  and 
namespaces  ■ 417 
?;  ternary  if-eise-  164 
[ ];  array  indexing  ■ 105;  overioaded 
indexing  operator  ■ 519,  698 
^bitwiseexclusive-or  ■ 159 
^bitwise  ■ 160 
I , bitwise  or  ■ 159 
I I , logicai  or  ■ 158 
I =bitwise  ■ 160 

-bitwise  not/  ones  complement  ■ 159 
~,  destructor  ■ 287 
+ ■ 156, 163;  with  pointers  ■ 192 
++■  164;  with  pointers  ■ 190 
<■  158 


«■  160;  overioading  for  iostreams  ■ 518 
«^-  160 
<=■  158 

= ■ 166;  operator;  as  a private  function  ■ 
533;  automatic  creation  ■ 532;  operator, 
asa  private  function  ■ 709;  overioading  ■ 
521 

— 158, 166 
>■  158 

->;  overioading  the  smart  pointer  operator 
■ 509;  struct  member  seiection  via 
pointer  ■ 178 
overioading  ■ 514 
>=■  158 

»■  160;  iostreams;  operator  ■ 106; 

overioading  ■ 518 
»=■  160 
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abort( ) ■ 409 

abstract;  based  asses  and  purevirtuai 
functions  ■ 646;  data  type  ■ 129,  239 
abstraction  ■ 22 

access;  control  ■ 260;  run-time  ■ 275; 
function  ■ 379;  specifiers  ■ 29,  261;  and 
object  layout  ■ 269;  order  for  ■ 263 
accessors  ■ 380 
actor,  in  use  cases  ■ 50 
addition  (-f-)  ■ 156 

address;  const  ■ 339;  each  object  must  have 
a uniqueaddress  ■ 241;  eiement  ■ 134; 
function  ■ 198,  391;  memory  ■ 133;  object 
■ 265;  pass  as  const  references  ■ 473; 
passing  and  returning  with  const  ■ 349; 
struct  object  ■ 178 
address-of  (&)  ■ 164 
aggregate  ■ 105;  const  aggregates  ■ 337; 
initiaiization  ■ 201,  301;  and  structures  ■ 
302 

aggregation  ■ 30 
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algorithms,  Standard  C-H-Library  ■ 742 
aliasing:  namespace  ■ 415;  solving  with 
reference  counting  and  copy-on- write  ■ 
527 

Allison,  Chuck  ■ 2,  776 
allocation:  dynamic  memory  allocation  ■ 
223,  548;  memory,  and  efficiency  ■ 566; 
storage  ■ 292 

alternate  linkage  specification  ■ 442 
ambiguity  ■ 244;  during  automatic  type 
conversion  ■ 540;  with  namespaces  ■ 420 
analysis:  and  design,  object-oriented  ■ 44; 
paralysis  ■ 45;  requirements  analysis  ■ 

48 

and:  & bitwise  ■ 159, 166;  &&  logical  ■ 158, 
166;  &&  logical  and  ■ 173 
and_eq,  &=(bltwiseand-assignment)  ■ 173 
anonymous  union  ■ 320 
ANSI  Standard  C-H--  14 
argc  ■ 187 

arguments:  argument-passing  guidelines  ■ 
455;  command  line  ■ 187,  252;  const  ■ 
344;  constructor  ■ 286;  default  ■ 310,  311, 
321;  argument  as  a flag  ■ 329;  destructor 

■ 287;  empty  argu  ment  I i st,  C vs.  C -H-  ■ 
114;  function  ■ 81, 138;  indeterminate 
list  ■ 114;  macro  ■ 374;  mnemonic  names 

■ 83;  name  decoration  ■ 312;  overloading 
vs.  default  arguments  ■ 324;  passing  ■ 
450;  placeholder  ■ 323;  preferred 
approach  to  argument  passing  ■ 351; 
references  ■ 451;  return  values,  operator 
overloading  ■ 505;  trailing  and  defaults  ■ 
322;  unnamed  ■ 114;  variable  argument 
list  ■ 114,  243;  without  identifiers  ■ 323 

argv  ■ 187 

arithmetic,  pointer  ■ 190 
array  ■ 182;  automatic  counting  ■ 301; 
bound s-checked,  using  templates  ■ 697; 
calculating  size  ■ 302;  definition, 
limitations  ■ 338;  indexing,  overloaded 
operator  []  ■ 698;  initializing  to  zero  ■ 
301;  insidea  class  ■ 353;  making  a 
pointer  look  I ike  an  array  ■ 564;  new  & 
delete  ■ 563;  of  pointers  ■ 187;  of 
pointers  to  functions  ■ 201;  off-by-one 
error  ■ 301;  overloading  new  and  delete 


for  arrays  ■ 573;  pointers  and  ■ 184; 
static  ■ 692;  static  initialization  ■ 425 
asctimef ) ■ 384 

assembly-language:  asm  in-line  assembly- 
language  keyword  ■ 173;  CALL  ■ 458; 
code  for  a function  call  ■ 456;  code 
generated  by  a virtual  function  ■ 642; 
RETURN  ■ 458 

assertf ):  macro  in  Standard  C ■ 197,  223, 
396 

assignment  ■ 156,  301;  disallowing  ■ 533; 
memberwise  ■ 532,  600;  operator  ■ 505; 
overloading  ■ 521;  pointer,  const  and 
non-const  ■ 343;  self-assignment  in 
operator  overloading  ■ 523 
assuref ) ■ 757;  from  required  ■ 237 
atexitf ) ■ 409 
atof( ) ■ 188, 189 
atoi( ) ■ 188 
atol( ) ■ 188 

auto  keyword  ■ 149,  414 
auto-decrement  operator  ■ 128 
auto-increment  operator  ■ 106, 128 
automatic:  counting,  and  arrays  ■ 301; 
creation  of  operator=-  532;  destructor 
calls  ■ 297;  type  conversion  ■ 228,  533; 
pitfalls  ■ 539;  preventing  with  the 
keyword  explicit  ■ 534;  variable  - 42, 
149, 153 


B 

backslash  ■ 95 
backspace  ■ 95 
bad_alloc  ■ 572 

base:  abstract  base  classes  and  pure  virtual 
functions  ■ 646;  based  ass  interface  ■ 
633;  fragile  based  ass  problem  ■ 276; 
types  ■ 32;  virtual  keyword  in  derived- 
class  declarations  ■ 632 
basic  concepts  of  object-oriented 
programming  (OOP)  ■ 22 
BASIC  language  ■ 68,  77 
Beck,  Kent  ■ 779 
behavior  ■ 219 

binary  operators  ■ 160;  examples  of  all 
overloaded  ■ 493;  overloaded  ■ 487 
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binding:  dynamic  binding  ■ 631;  eariy  ■ 38, 
644;  function  cail  binding  ■ 631,  641;  late 

■ 38,  631;  run-time  binding  ■ 631 
bit  bucket  ■ 162 

bitand,  & (bitwise  and)  ■ 173 
bitcopy  ■ 468 

bitcopy,  vs.  initialization  ■ 460 
bitor,  I (bitwise  or)  ■ 173 
bit-shifting  ■ 162 

bitwise;  and  operator  & ■ 159, 166;  const  ■ 
362;  exclusive-or,  xor''-  159;  explicit 
bitwise  and  logicai  operators  - 173;  not 
~ ■ 159;  operators  ■ 159;  or  operator  | ■ 
159, 166 

bioat,  code  ■ 391 

biock;  access  ■ 269;  and  storage  ai location  ■ 
292;  definition  ■ 289 
Booch,  Grady  ■ 779 

book;  design  & production  ■ 18;  errors, 
reporting  ■ 16 
booi  ■ 125, 195 

Boolean  ■ 117, 158, 163;  algebra  ■ 159;  and 
floating  point  ■ 159;  bool,  true  and  false 

■ 131 

bound s-checked  array,  with  templates  ■ 

697 

break,  keyword  ■ 122 
bucket,  bit  ■ 162 

bugs;  common  pitfalls  with  operators  ■ 

166;  finding  ■ 292;  from  casts  ■ 168;  with 
temporaries  - 348 

built-intype-  129;  basic-  129;  initializer  for 
a static  variabie  - 408; 
pseudoconstructor;  caiisfor  - 589;  form 
for  built-in  types  - 381 
byte  - 133 


c 

C - 289;  #define-  340;  backward 
compatibility  - 73;  C programmers 
learning  C-H--  628;  C-H-compatibiiity  - 
235;  compiling  with  C-H--  305;  concepts 
- 2;  const  - 338;  converting  from  C to 
C-H--  230,  760;  difference  with  C-H- 
when  defining  variabies  - 145;  empty 
argu  ment  I i st,  C vs.  C -H-  - 114;  f i nd  i ng 


probiems  in  old  code  - 70;  function 
library  - 116;  fundamentais  - 112;  heap  - 
550;  hoie  in  the  type  system,  via  void* - 
450;  ISO  Standard  C - 14;  libraries  - 89, 
219;  linkage  - 338;  linking  compiled  C 
code  with  C-H--  442;  name  collisions  - 
68;  operators  and  their  use  - 156; 
passing  and  returning  variables  by 
value  - 455;  pitfalls  - 227;  preprocessor  - 
334;  safety  hole  during  linking  - 314; 
Standard  library  function;  abort( ) - 409; 
atexit( ) - 409;  exit( ) - 409;  Thinking  in  C 
CD  ROM  - 776 

C-H-;  automatic  typed ef  for  struct  and 
class  - 231;  C compatibility  - 235;  C 
programmers  learning  C-H--  628; 
cfront,  original  C-H- compiler  - 237; 
compiling  C - 305;  converting  from  C to 
C-H--  230,  760;  data  - 129;  difference 
with  C when  defining  variables  - 145; 
efficiency  - 66;  empty  argument  list,  C 
vs.  C-H--  114;  explicit  casts  - 167; 
finding  C errors  by  recompiling  in  C-H- 

- 314;  first  program  - 90;  GN  U Compiler 

- 71;  hybrid  object-oriented  language, 
and  friend  - 269;  implicit  structure 
address  passing  - 231;  linking  compiled 
C code  with  C-H--  442;  major  language 
features  - 682;  meaning  of  the  language 
name  - 129;  object-based  C-H--  628;  one 
definition  rule  - 244;  operators  and  their 
use-  156;  programming  guidelines - 
760;  Standard  C-H--  14;  Standards 
Committee  - 14;  strategies  for  transition 
to  - 68;  stricter  type  checking  - 227; 
strongly  typed  language  - 450;  why  it 
succeeds  - 64 

calculating  array  size  - 302 
CALL,  assembly-language  - 458 
calling  a member  function  for  an  object  - 
239 

calloc( ) - 223,  550,  554 
Carolan,  john  - 277 
Carroll,  Lewis  - 277 
case-  124 

cassert  standard  header  file  - 197 
cast  - 40, 135, 164,  276,  552,  630;  C-H- 
explicit  casts  - 167;  casting  away 
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constness  ■ 363;  casting  void  pointers  ■ 
235;  const_cast  ■ 170;  explicit castfor 
upcasting  ■ 681;  explicit  keyword  ■ 678; 
operators  ■ 166;  pointer  assignment  ■ 
343;  reinterpret  cast  ■ 171;  static_cast  ■ 
169 

cat,  Cheshire  - 277 
catch  clauses  ■ 572 

CD  ROM;  seminars  on  CD-ROM  from 
MindView  ■ 16;  Thinking  in  C, 
Foundations  for  Java  & C-H- (packaged 
with  book)  ■ 2, 15, 112 
cfront,  original  C-H- compiler  ■ 237 
chapter  overviews  ■ 7 
char  ■ 96, 130, 132;  sizeof  ■ 173 
character  ■ 154;  array  literals  ■ 343; 
character  array  concatenation  ■ 96; 
constants  ■ 155 
characteristics  ■ 219 
check  for  self-assignment  in  operator 
overloading  ■ 505 
Cheshire  cat  ■ 277 
cin  ■ 97 

clashes,  name  ■ 229 

class  ■ 25,  76,  271;  abstract  base  cl  asses  and 
pure  virtual  functions  ■ 646;  adding 
new  virtual  functions  in  the  derived 
class  ■ 652;  aggregate  initialization  ■ 302; 
class  definition  and  inlinefunctions  ■ 
378;  compile-time  constants  inside  ■ 

353,  356,  358;  composition,  and  copy- 
constructor  ■ 469;  const  and  enum  in  ■ 
353;  container  class  templates  and 
virtual  functions  ■ 743;  creators  ■ 28; 
declaration  ■ 277;  of  a nested  friend 
class  ■ 514;  defining  the  interface  ■ 62; 
definition  ■ 277;  difference  between  a 
union  and  a class  ■ 319;  duplicate  class 
definitions  and  templates  ■ 699;  fragile 
base-class  problem  ■ 276;  generated  by 
macro  ■ 594;  generated  cl  asses  for 
templates  ■ 699;  handle  class  ■ 275; 
inheritance;  and  copy-constructor  ■ 471; 
diagrams  ■ 617;  initialization, 
memberwise  - 471;  instance  of  - 24; 
keyword  - 31;  local  - 428;  nested  - 428; 
iterator  - 512,  721;  overioading  new  and 
delete  for  a class  - 570;  pointers  in,  and 


overioading  operator=-  524;  staticciass 
objects  insidefunctions  - 408;  static  data 
members  - 423;  static  member  functions 
- 429;  templates  - 742;  using  const  with  - 
352 

cl  ass-responsi  bi  I i ty-col  I aborati  on  (C  RC ) 
cards  - 52 

cleanup  - 227,  666;  automatic  destructor 
callswith  inheritance  and  composition  - 
592;  initialization  and  cleanup  on  the 
heap  - 548 

client  programmer  - 28,  260 
code;  assembly  for  a function  call  - 456; 
bloat  - 391;  comment  tags  in  listings  - 
750;  consulting,  mentoring,  and  design 
and  code  walkthroughs  from 
MindView  - 16;  generator  - 79; 
organization  - 248;  header  files  - 244; 
program  structure  when  writing  code  - 
93;  re-use  - 583;  source  availability  - 12; 
table-driven  - 201 
collection  - 510,  719 
collector,  garbage  - 42 
collision,  linker  - 244 
comma  operator  - 165,  508 
command  line-  252;  arguments  - 187 
comment  tag;  for  linking  - 148;  in  source- 
codelistings-  750 
comments,  makefile  - 204 
committee,  C-H- Standards  - 14 
common  interface  - 647 
compaction,  heap  - 225 
compatibility;  C & C-H--  235;  with  C - 98 
compilation;  needless  - 276;  process  - 79; 

separate  - 78;  separate,  and  make  - 202 
compi  I e ti  me  constants  - 335 
compiler  - 76,  77;  creating  default 

constructor  - 304;  original  C-H- compiler 
cfront  - 237;  running  - 95;  support  - 15 
compiling  C with  C-H--  305 
compi,  -ones  complement  - 173 
complicated;  declarations  & definitions  - 
199;  expressions,  and  operator 
overioading  - 488 

composite;  array  - 182;  type  creation  - 174 
composition  - 30,  584,  607;  combining 
composition  & inheritance  - 591;  copy- 
constructor  - 469;  member  object 
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initialization  ■ 589;  vs.  inheritance  - 604, 
620,  740 

concatenation,  character  array  ■ 96 
concept,  high  ■ 48 
conditional  operator  ■ 164 
conditional,  in  for  loop  ■ 121 
const  ■ 153,  334;  address  of  ■ 339; 
aggregates  ■ 337;  casti  ng  away  ■ 363; 
character  array  literals  ■ 343;  compile- 
time constants  in  classes  ■ 356;  const 
reference  function  arguments  ■ 351; 
correctness  ■ 367;  enum  in  classes  ■ 353; 
evaluation  point  of  ■ 337;  extern  ■ 339; 
function  arguments  and  return  values  ■ 
344;  in  C ■ 338;  initializing  data 
members  ■ 355;  logical  ■ 362;  member 
function  ■ 352;  and  objects  ■ 359; 
mutable  ■ 362;  pass  addresses  as  const 
references  ■ 473;  pointer  to  const  ■ 171; 
pointers  ■ 340;  reference  ■ 345,  453;  and 
operator  overloading  ■ 505;  return  by 
value  as  const  ■ 345;  and  operator 
overloading  ■ 507;  safety  ■ 336; 
temporaries  are  automatically  const  ■ 
347 

const_cast  ■ 170 

constant  ■ 153;  character  ■ 155;  compile- 
time ■ 335;  insideclasses  ■ 358;  folding  ■ 
335,  339;  named  ■ 153;  templates, 
constants  in  ■ 703;  values  ■ 154 
constructor  ■ 285,  548,  551,  665;  arguments 
■ 286;  automatic  type  conversion  ■ 534; 
behavior  of  virtual  functions  inside 
constructors  ■ 664;  copy-constructor  ■ 
432,  450,  455,  463,  657;  alternatives  to  ■ 
471;  vs.  operator=-  521;  creating  a new 
object  from  an  existing  object  ■ 462; 
default  ■ 304,  327,  408,  470,  563; 
inheritance  ■ 663;  synthesized  by  the 
compiler  ■ 304;  doesn't  automatically 
inherit  ■ 600;  efficiency  ■ 663;  global 
object  ■ 410;  initialization  and  cleanup 
on  the  heap  - 548;  initializer  list  - 353, 
589,  664;  pseudoconstructors  - 589; 
inline-  392;  installing  the  VPTR  - 643; 
memberwise  initialization  - 600;  name- 
285;  new  operator,  memory  exhaustion 
- 576;  order  of  construction  with 


inheritance  - 665;  order  of  constructor 
calls  - 663;  and  destructor  calls  - 592; 
overloading  - 310,  319;  private  - 709; 
pseudo-constructor  - 562;  return  value  - 
287;  tracking  creations  and  destructions 

- 709;  virtual  functlons&  constructors  - 
662 

consulting,  mentoring,  and  design  and 
code  walkthroughs  from  MindView  - 
16 

container  - 510,  719;  container  class 
templates  and  virtual  functions  - 743; 
delete  - 671;  iterators  - 690;  new,  delete, 
and  containers  - 692;  ownership  - 555, 
671,  713;  polymorphism  - 738;  Standard 
C-H- Library  - 104;  vector  - 102 
context,  and  overloading  - 310 
continuation,  namespace  - 415 
continue,  keyword  - 122 
control;  access  - 29,  260;  run-time  - 275; 
access  specifiers  - 261;  expression,  used 
with  a for  loop  - 106 

controlling;  execution  - 117;  linkage  - 412 
conversion;  automatic  type  conversion  - 
533;  narrowing  conversions  - 170; 
pitfalls  in  automatic  type  conversion  - 
539;  preventing  automatic  type 
conversion  with  the  keyword  explicit  - 
534;  to  numbers  from  char*  - 188 
converting  from  C to  C-H--  230,  760 
copy-constructor  - 432,  450,  455,  463,  508, 
657,  730;  alternatives  - 471;  composition 

- 469;  default  - 468;  inheritance  - 471; 
private  - 471,  709;  upcasting  and  the 
copy-constructor  - 617;  vs.  operator=- 
521 

copying  pointers  insideclasses  - 524 
copy-on-wrlte(COW)  - 527 
copyright  notice,  source  code  - 12 
correctness,  const  - 367 
costs,  startup  - 71 

counting;  automatic,  and  arrays  - 301; 

reference  - 526 
cout  - 90,  91 
cover  design,  book  - 17 
C RC , cl  ass-responsi  bl  I i ty-col  I aborati  on 
cards  - 52 
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creating:  functions  in  C and  C++-  112; 
new  object  from  an  existing  object  ■ 462; 
objects  on  the  heap  ■ 554 
crisis,  software  - 8 
cstdiib  standard  header  file  - 188 
cstring  standard  header  file  - 269 
c-v  qualifier  - 366 
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data;  defining  storage  for  static  members  - 
424;  initializing  const  members  - 355; 
static  area  - 406;  static  members  inside  a 
class  - 423 

datatype;  abstract  - 129,  239;  built-in  - 129; 
equivalence  to  class  - 26;  user-defined  - 
129 

debugging  - 78;  assertO  macro  - 197;  flags  - 
194;  preprocessor  flags  - 194;  requireh  - 
396;  run-time  - 195;  using  the 
preprocessor  - 395 
decimal  - 154 

declaration  - 81;  all  possible  combi  nations  - 
141;  analyzing  complex  - 199;  and 
definition  - 243;  class  - 277;  nested 
friend  - 514;  const  - 340;  forward  - 151; 
function  - 116,  233,  313;  declaration 
syntax  - 82;  not  essential  in  C - 228; 
header  files  - 242,  244;  structure  - 265; 
using,  for  namespaces  - 421;  variabie; 
declaration  syntax  - 83;  point  of 
deciaration  & scope  - 145;  virtual  - 632; 
base-class  declarations  - 632;  derived- 
cl ass  declarations  - 632 
decoration,  name  - 230,  231,  237,  442; 
overloading  - 311 

decoupling  - 628;  via  polymorphism  - 39 
decrement  - 128, 164;  and  increment 
operators  - 506;  overloading  operator  - 
493 

default;  argument  - 310,  311,  321;  as  a flag  - 
329;  vs.  overloading  - 324;  constructor  - 
304,  327,  408,  470,  563;  inheritance  - 663; 
copy-constructor  - 468;  default  values  in 
templates  - 703;  keyword  - 124 
defining;  function  pointer  - 198;  initializing 
at  the  same  ti me  - 290;  initializing 


variables  - 130;  variable  - 145;  anywhere 
in  the  scope  - 145 

definition  - 81;  array  - 338;  block  - 289;  class 

- 277;  complex  function  definitions  - 
198;  const  - 340;  declaration  - 243; 

d u pi  i cate  cl  ass  d ef  i ni  ti  ons  and 
templates  - 699;  formatting  pointer 
definitions  - 342;  function  - 83;  non- 
i nl  i ne  tempi  ate  member  f uncti  on 
definitions  - 699;  object  - 285;  pure 
virtual  function  definitions  - 651; 
storage  for  static  data  members  - 424; 
structure  definition  in  a header  file  - 234 
delete  - 164,  223,  553;  calling  delete  for  zero 

- 327;  delete-expression  - 553,  566; 
keyword  - 42;  multi  pie  deletions  of  the 
same  object  - 553;  new;  and  containers  - 
692;  for  arrays  - 563;  overioading  new 
and  delete  - 566;  array  - 573;  class  - 570; 
global  - 568;  void*  deleting  is  a bug  - 
555;  zero  pointer  - 553 

Demarco,  Tom  - 781 
dependency;  makefile  - 204;  static 
initialization  - 432 

deprecation,  of  -H-with  a bool  flag  - 131 
dereference;  * - 164;  dereferencing  function 
pointers  - 200;  pointer  - 137 
derived;  adding  new  virtual  functions  in 
the  derived  class  - 652;  types  - 32; 
virtual  keyword  in  derived-class 
declarations  - 632 

design;  analysis  and  design,  object- 
oriented  - 44;  book;  cover  - 17;  design 
and  production  - 18;  consulting, 
mentoring,  and  design  and  code 
walkthroughs  from  MindView  - 16;  five 
stages  of  object  design  - 54;  inlines  - 380; 
mistakes  - 279;  pattern,  iterator  - 719; 
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function  call  - 372,  377;  memory 
manager  - 554;  size  overhead  of  virtual 
functions  - 637 

overloading  - 95;  «and  »for  iostreams  - 
518;  assignment  - 521;  choosing 
between  members  and  non-members, 
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post-decrement  - ■ 128 
postfix  operator  increment  & decrement  ■ 
493 

post-increment  -H-  ■ 128 
precedence,  operator  ■ 127 
preconditions  - 758 
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779;  in  the  large  - 68;  incremental 
process  - 614;  multiparadigm  - 24;  pair  - 
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values,  references  - 451;  keyword  - 115; 
operator;  overloaded  return  type  - 488; 
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- 240 

slicing;  object  slicing  - 655 
Smalltalk  - 24,  80,  645,  694,  702 
smart  pointer  operator  ->  - 509,  730 
software;  crisis  - 8;  development 
methodology  - 45 
solution  space  - 23 
solutions,  exercise  - 12 
sourcecodeavailability  - 12 
source- level  debugger  - 78 
space;  problem  - 23;  solution  - 23 
specification;  incomplete  type  - 265,  277; 

system  specification  - 48 
specifier;  access  specifiers  - 29,  261;  no 
required  order  in  a class  - 263;  to 
modify  basic  built-in  types  - 132 
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ternary  operator  - 164 
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explicit  cast  for  upcasting  - 681;  pointer 
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by-value  - 137;  preprocessor  value 
substitution  - 334;  return  - 81;  returning 
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vpointer,  abbreviated  asVPTR  - 637 
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End-User  License  Agreement  for  Microsoft  Software 

IMPORTANT- READ  CAREFULLY:  This  Microsoft  End-User  License 
Agreement  ("EULA")  is  a legal  agreement  between  you  (either  an 
individual  or  a single  entity)  and  Microsoft  Corporation  for  the 
Microsoft  software  product  included  in  this  package,  which  includes 
computer  software  and  may  include  associated  media,  printed 
materials,  and  "online"  or  electronic  documentation  ("SOFTWARE 
PRODUCT").  The  SOFTWARE  PRODUCT  also  includes  any  updates  and 
supplements  to  the  original  SOFTWARE  PRODUCT  provided  to  you  by 
Microsoft.  By  installing,  copying,  downloading,  accessing  or  otherwise 
using  the  SOFTWARE  PRODUCT,  you  agree  to  be  bound  by  the  terms 
of  this  EULA.  If  you  do  not  agree  to  the  terms  of  this  EULA,  do  not 
install,  copy,  or  otherwise  use  the  SOFTWARE  PRODUCT. 

SOFTWARE  PRODUCT  LICENSE 

The  SOFTWARE  PRODUCT  is  protected  by  copyright  laws  and 
international  copyright  treaties,  as  well  as  other  intellectual  property 
laws  and  treaties.  The  SOFTWARE  PRODUCT  is  licensed,  not  sold. 

1.  GRANT  OF  LICENSE.  This  EULA  grants  you  the  following  rights: 

1.1  License  Grant.  Microsoft  grants  to  you  as  an  individual,  a personal 
nonexclusive  license  to  make  and  use  copies  of  the  SOFTWARE 
PRODUCT  for  the  sole  purposes  of  evaluating  and  learning  how  to  use 
the  SOFTWARE  PRODUCT,  as  may  be  instructed  in  accompanying 
publications  or  documentation.  You  may  install  the  software  on  an 
unlimited  number  of  computers  provided  that  you  are  the  only 
individual  using  the  SOFTWARE  PRODUCT. 

1.2  Academic  Use.  You  must  be  a "Oualified  Educational  User"  to  use 
the  SOFTWARE  PRODUCT  in  the  manner  described  in  this  section.  To 
determine  whether  you  are  a Oualified  Educational  User,  please 
contact  the  Microsoft  Sales  Information  Center/One  Microsoft 
Way/Redmond,  WA  98052-6399  or  the  Microsoft  subsidiary  serving 
your  country.  If  you  are  a Oualified  Educational  User,  you  may  either: 

(i)  exercise  the  rights  granted  in  Section  1.1,  OR 

(ii)  if  you  intend  to  use  the  SOFTWARE  PRODUCT  solely  for 
instructional  purposes  in  connection  with  a class  or  other  educational 
program,  this  EULA  grants  you  the  following  alternative  license 
models: 

(A)  Per  Computer  Model.  For  every  valid  license  you  have  acquired  for 
the  SOFTWARE  PRODUCT,  you  may  install  a single  copy  of  the 
SOFTWARE  PRODUCT  on  a single  computer  for  access  and  use  by  an 
unlimited  number  of  student  end  users  at  your  educational  institution. 
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provided  that  all  such  end  users  comply  with  all  other  terms  of  this 
EULA,  OR 

(B)  Per  License  Model.  If  you  have  multiple  licenses  for  the  SOFTWARE 
PRODUCT,  then  at  any  time  you  may  have  as  many  copies  of  the 
SOFTWARE  PRODUCT  in  use  as  you  have  licenses,  provided  that  such 
use  is  limited  to  student  or  faculty  end  users  at  your  educational 
institution  and  provided  that  all  such  end  users  comply  with  all  other 
terms  of  this  EULA.  For  purposes  of  this  subsection,  the  SOFTWARE 
PRODUCT  is  "in  use"  on  a computer  when  it  is  loaded  into  the 
temporary  memory  (i.e.,  RAM)  or  installed  into  the  permanent  memory 
(e.g.,  hard  disk,  CD  ROM,  or  other  storage  device)  of  that  computer, 
except  that  a copy  installed  on  a network  server  for  the  sole  purpose 
of  distribution  to  other  computers  is  not  "in  use".  If  the  anticipated 
number  of  users  of  the  SOFTWARE  PRODUCT  will  exceed  the  number 
of  applicable  licenses,  then  you  must  have  a reasonable  mechanism  or 
process  in  place  to  ensure  that  the  number  of  persons  using  the 
SOFTWARE  PRODUCT  concurrently  does  not  exceed  the  number  of 
licenses. 

2.  DESCRIPTION  OF  OTHER  RIGHTS  AND  LIMITATIONS. 

• Limitations  on  Reverse  Engineering,  Decompilation,  and 
Disassembly.  You  may  not  reverse  engineer,  decompile,  or  disassemble 
the  SOFTWARE  PRODUCT,  except  and  only  to  the  extent  that  such 
activity  is  expressly  permitted  by  applicable  law  notwithstanding  this 
limitation. 

• Separation  of  Components.  The  SOFTWARE  PRODUCT  is  licensed  as 
a single  product.  Its  component  parts  may  not  be  separated  for  use  on 
more  than  one  computer. 

• Rental.  You  may  not  rent,  lease  or  lend  the  SOFTWARE  PRODUCT. 

• Trademarks.  This  EULA  does  not  grant  you  any  rights  in  connection 
with  any  trademarks  or  service  marks  of  Microsoft. 

• Software  Transfer.  The  initial  user  of  the  SOFTWARE  PRODUCT  may 
make  a one-time  permanent  transfer  of  this  EULA  and  SOFTWARE 
PRODUCT  only  directly  to  an  end  user.  This  transfer  must  include  all  of 
the  SOFTWARE  PRODUCT  (including  all  component  parts,  the  media 
and  printed  materials,  any  upgrades,  this  EULA,  and,  if  applicable,  the 
Certificate  of  Authenticity).  Such  transfer  may  not  be  by  way  of 
consignment  or  any  other  indirect  transfer.  The  transferee  of  such  one- 
time transfer  must  agree  to  comply  with  the  terms  of  this  EULA, 
including  the  obligation  not  to  further  transfer  this  EULA  and 
SOFTWARE  PRODUCT. 

• No  Support.  Microsoft  shall  have  no  obligation  to  provide  any 
product  support  for  the  SOFTWARE  PRODUCT. 

• Termination.  Without  prejudice  to  any  other  rights,  Microsoft  may 
terminate  this  EULA  if  you  fail  to  comply  with  the  terms  and  conditions 
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of  this  EULA.  I n such  event,  you  must  destroy  all  copies  of  the 
SOFTWARE  PRODUCT  and  all  of  its  component  parts. 

3.  COPYRIGHT.  All  title  and  intellectual  property  rights  in  and  to  the 
SOFTWARE  PRODUCT  (including  but  not  limited  to  any  images, 
photographs,  animations,  video,  audio,  music,  text,  and  "applets" 
incorporated  into  the  SOFTWARE  PRODUCT),  the  accompanying 
printed  materials,  and  any  copies  of  the  SOFTWARE  PRODUCT  are 
owned  by  Microsoft  or  its  suppliers.  All  title  and  intellectual  property 
rights  in  and  to  the  content  which  may  be  accessed  through  use  of  the 
SOFTWARE  PRODUCT  is  the  property  of  the  respective  content  owner 
and  may  be  protected  by  applicable  copyright  or  other  intellectual 
property  laws  and  treaties.  This  EULA  grants  you  no  rights  to  use  such 
content.  All  rights  not  expressly  granted  are  reserved  by  Microsoft. 

4.  BACKUP  COPY.  After  installation  of  one  copy  of  the  SOFTWARE 
PRODUCT  pursuant  to  this  EULA,  you  may  keep  the  original  media  on 
which  the  SOFTWARE  PRODUCT  was  provided  by  Microsoft  solely  for 
backup  or  archival  purposes.  If  the  original  media  is  required  to  use 
the  SOFTWARE  PRODUCT  on  the  COMPUTER,  you  may  make  one  copy 
of  the  SOFTWARE  PRODUCT  solely  for  backup  or  archival  purposes. 
Except  as  expressly  provided  in  this  EULA,  you  may  not  otherwise 
make  copies  of  the  SOFTWARE  PRODUCT  or  the  printed  materials 
accompanying  the  SOFTWARE  PRODUCT. 

5.  U.S.  GOVERNMENT  RESTRICTED  RIGHTS.  The  SOFTWARE 
PRODUCT  and  documentation  are  provided  with  RESTRICTED  RIGHTS. 
Use,  duplication,  or  disclosure  by  the  Government  is  subject  to 
restrictions  as  set  forth  in  subparagraph  (c)(l)(ii)  of  the  Rights  in 
Technical  Data  and  Computer  Software  clause  at  DEARS  252.227-7013 
or  subparagraphs  (c)(1)  and  (2)  of  the  Commercial  Computer 
Software- Restricted  Rights  at  48  CFR  52.227-19,  as  applicable. 
Manufacturer  is  Microsoft  Corporation/One  Microsoft  Way/Redmond, 

WA  98052-6399. 

6.  EXPORT  RESTRICTIONS.  You  agree  that  you  will  not  export  or  re- 
export the  SOFTWARE  PRODUCT,  any  part  thereof,  or  any  process  or 
service  that  is  the  direct  product  of  the  SOFTWARE  PRODUCT  (the 
foregoing  collectively  referred  to  as  the  "Restricted  Components"),  to 
any  country,  person,  entity  or  end  user  subject  to  U.S.  export 
restrictions.  You  specifically  agree  not  to  export  or  re-export  any  of  the 
Restricted  Components  (i)  to  any  country  to  which  the  U.S.  has 
embargoed  or  restricted  the  export  of  goods  or  services,  which 
currently  include,  but  are  not  necessarily  limited  to  Cuba,  Iran,  Iraq, 
Libya,  North  Korea,  Sudan  and  Syria,  or  to  any  national  of  any  such 
country,  wherever  located,  who  intends  to  transmit  or  transport  the 
Restricted  Components  back  to  such  country;  (ii)  to  any  end-user  who 
you  know  or  have  reason  to  know  will  utilize  the  Restricted 
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Components  in  the  design,  development  or  production  of  nuclear, 
chemical  or  biological  weapons;  or  (iii)  to  any  end-user  who  has  been 
prohibited  from  participating  in  U.S.  export  transactions  by  any  federal 
agency  of  the  U.S.  government.  You  warrant  and  represent  that 
neither  the  BXA  nor  any  other  U.S.  federal  agency  has  suspended, 
revoked,  or  denied  your  export  privileges. 

7.  NOTE  ON  JAVA  SUPPORT.  THE  SOFTWARE  PRODUCT  MAY  CONTAIN 
SUPPORT  FOR  PROGRAMS  WRITTEN  IN  JAVA.  J AVA  TECHNOLOGY  IS 
NOT  FAULT  TOLERANT  AND  IS  NOT  DESIGNED,  MANUFACTURED,  OR 
INTENDED  FOR  USE  OR  RESALE  AS  ON-LINE  CONTROL  EOUIPMENT  IN 
HAZARDOUS  ENVIRONMENTS  REOUIRING  FAIL-SAFE  PERFORMANCE, 
SUCH  AS  IN  THE  OPERATION  OF  NUCLEAR  FACILITIES,  AIRCRAFT 
NAVIGATION  OR  COMMUNICATION  SYSTEMS,  AIR  TRAFFIC  CONTROL, 
DIRECT  LIFE  SUPPORT  MACHINES,  OR  WEAPONS  SYSTEMS,  IN  WHICH 
THE  FAILURE  OF  J AVA  TECHNOLOGY  COULD  LEAD  DIRECTLY  TO 
DEATH,  PERSONAL  INJURY,  OR  SEVERE  PHYSICAL  OR 
ENVI  RONMENTAL  DAMAGE. 

MISCELLANEOUS 

If  you  acquired  this  product  in  the  United  States,  this  EULA  is  governed 
by  the  laws  of  the  State  of  Washington. 

If  you  acquired  this  product  in  Canada,  this  EULA  is  governed  by  the 
laws  of  the  Province  of  Ontario,  Canada.  Each  of  the  parties  hereto 
irrevocably  attorns  to  the  Jurisdiction  of  the  courts  of  the  Province  of 
Ontario  and  further  agrees  to  commence  any  litigation  which  may  arise 
hereunder  in  the  courts  located  in  the  Judicial  District  of  York,  Province 
of  Ontario. 

If  this  product  was  acquired  outside  the  United  States,  then  local  law 
may  apply. 

Should  you  have  any  questions  concerning  this  EULA,  or  if  you  desire 
to  contact  Microsoft  for  any  reason,  please  contact 
Microsoft,  or  write:  Microsoft  Sales  Information  Center/One  Microsoft 
Way/Redmond,  WA  98052-6399. 

LIMITED  WARRANTY 

LIMITED  WARRANTY.  Microsoft  warrants  that  (a)  the  SOFTWARE 
PRODUCT  will  perform  substantially  in  accordance  with  the 
accompanying  written  materials  for  a period  of  ninety  (90)  days  from 
the  date  of  receipt,  and  (b)  any  Support  Services  provided  by  Microsoft 
shall  be  substantially  as  described  in  applicable  written  materials 
provided  to  you  by  Microsoft,  and  Microsoft  support  engineers  will 
make  commercially  reasonable  efforts  to  solve  any  problem.  To  the 
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extent  allowed  by  applicable  law,  implied  warranties  on  the  SOFTWARE 
PRODUCT,  if  any,  are  limited  to  ninety  (90)  days.  Some 
states/jurisdictions  do  not  allow  limitations  on  duration  of  an  implied 
warranty,  so  the  above  limitation  may  not  apply  to  you. 

CUSTOMER  REMEDIES.  Microsoft's  and  its  suppliers'  entire  liability  and 
your  exclusive  remedy  shall  be,  at  Microsoft's  option,  either  (a)  return 
of  the  price  paid,  if  any,  or  (b)  repair  or  replacement  of  the  SOFTWARE 
PRODUCT  that  does  not  meet  Microsoft's  Limited  Warranty  and  that  is 
returned  to  Microsoft  with  a copy  of  your  receipt.  This  Limited 
Warranty  is  void  if  failure  of  the  SOFTWARE  PRODUCT  has  resulted 
from  accident,  abuse,  or  misapplication.  Any  replacement  SOFTWARE 
PRODUCT  will  be  warranted  for  the  remainder  of  the  original  warranty 
period  or  thirty  (30)  days,  whichever  is  longer.  Outside  the  United 
States,  neither  these  remedies  nor  any  product  support  services 
offered  by  Microsoft  are  available  without  proof  of  purchase  from  an 
authorized  international  source. 

NO  OTHER  WARRANTIES.  TO  THE  MAXIMUM  EXTENT  PERMITTED  BY 
APPLICABLE  LAW,  MICROSOFT  AND  ITS  SUPPLIERS  DISCLAIM  ALL 
OTHER  WARRANTIES  AND  CONDITIONS,  EITHER  EXPRESS  OR 
IMPLIED,  INCLUDING,  BUT  NOT  LIMITED  TO,  I MPLI  ED  WARRANTI  ES 
OR  CONDITIONS  OF  MERCHANTABILITY,  FITNESS  FOR  A PARTICULAR 
PURPOSE,  TITLE  AND  NON-INFRINGEMENT,  WITH  REGARD  TO  THE 
SOFTWARE  PRODUCT,  AND  THE  PROVISION  OF  OR  FAILURE  TO 
PROVIDE  SUPPORT  SERVICES.  THIS  LIMITED  WARRANTY  GIVES  YOU 
SPECIFIC  LEGAL  RIGHTS.  YOU  MAY  HAVE  OTHERS,  WHICH  VARY  FROM 
STATE/JURISDICTION  TO  STATE/JURISDICTION. 

LIMITATION  OF  LIABILITY.  TO  THE  MAXIMUM  EXTENT  PERMITTED  BY 
APPLICABLE  LAW,  IN  NO  EVENT  SHALL  Ml CROSOFT  OR  ITS  SUPPLIERS 
BE  LIABLE  FOR  ANY  SPECIAL,  INCIDENTAL,  INDIRECTOR 
CONSEOUENTIAL  DAMAGES  WHATSOEVER  (INCLUDING,  WITHOUT 
LIMITATION,  DAMAGES  FOR  LOSS  OF  BUSINESS  PROFITS,  BUSINESS 
INTERRUPTION,  LOSS  OF  BUSINESS  INFORMATION,  OR  ANY  OTHER 
PECUNIARY  LOSS)  ARISING  OUT  OF  THE  USE  OF  OR  INABILITY  TO 
USE  THE  SOFTWARE  PRODUCT  OR  THE  FAI  LURE  TO  PROVI  DE 
SUPPORT  SERVICES,  EVEN  IF  MICROSOFT  HAS  BEEN  ADVISED  OF  THE 
POSSIBILITY  OF  SUCH  DAMAGES.  I N ANY  CASE,  MICROSOFT'S 
ENTIRE  LIABILITY  UNDER  ANY  PROVISION  OF  THIS  EULA  SHALL  BE 
LI  MITED  TO  THE  GREATER  OF  THE  AMOUNT  ACTUALLY  PAI  D BY  YOU 
FOR  THE  SOFTWARE  PRODUCT  OR  U.S.$5.00;  PROVIDED,  HOWEVER, 
IF  YOU  HAVE  ENTERED  INTO  A MICROSOFT  SUPPORT  SERVICES 
AGREEMENT,  MICROSOFT'S  ENTIRE  LIABILITY  REGARDING  SUPPORT 
SERVICES  SHALL  BE  GOVERNED  BY  THE  TERMS  OF  THAT  AGREEMENT. 
BECAUSE  SOME  STATES/JURISDICTIONS  DO  NOTALLOW  THE 
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EXCLUSION  OR  LIMITATION  OF  LIABILITY,  THE  ABOVE  LIMITATION 
MAY  NOT  APPLY  TO  YOU. 

0495  Part  No.  64358 
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LICENSE  AGREEMENT  FOR  MindView,  Inc.'s 
Thinking  in  C:  Foundations  for  C++  S<Java  CD-ROM 
by  Chuck  Allison 

This  CD  is  provided  together  with  the  book  "Thinking  in  C++  2nd 
edition,  Volume  1." 

READ  THI S AGREEMENT  BEFORE  USI NG  THI S "Thinking  in  C: 
Foundations  for  C++  & J ava"  (Flereafter  called  "CD").  BY  USI  NG  TFIE 
CD  YOU  AGREE  TO  BE  BOUND  BY  THE  TERMS  AND  CONDITIONS  OF 
THIS  AGREEMENT.  I F YOU  DO  NOT  AGREE  TO  THE  TERMS  AND 
CONDITIONS  OF  THIS  AGREEMENT,  IMMEDIATELY  RETURN  THE 
UNUSED  CD  FOR  A FULL  REFUND  OF  MONIES  PAID,  I F ANY. 

©2000  MindView  Inc.  All  rights  reserved.  Printed  in  the  U.S. 

SOFTWARE  REOUIREMENTS 

The  purpose  of  this  CD  is  to  provide  the  Content,  not  the  associated 
software  necessary  to  view  the  Content.  The  Content  of  this  CD  is  in 
HTML  for  viewing  with  Microsoft  Internet  Explorer  4 or  newer,  and  uses 
Microsoft  Sound  Codecs  available  in  Microsoft's  Windows  Media  Player 
for  Windows  or  the  Macintosh.  It  is  your  responsibility  to  correctly 
install  the  appropriate  Microsoft  software  for  your  system. 

The  text,  images,  and  other  media  included  on  this  CD  ("Content")  and 
their  compilation  are  licensed  to  you  subject  to  the  terms  and 
conditions  of  this  Agreement  by  MindView  Inc.,  having  a place  of 
business  at  5343  Valle  Vista,  La  Mesa,  CA  91941.  Your  rights  to  use 
other  programs  and  materials  included  on  the  CD  are  also  governed  by 
separate  agreements  distributed  with  those  programs  and  materials  on 
the  CD  (the  "Other  Agreements").  In  the  event  of  any  inconsistency 
between  this  Agreement  and  the  Other  Agreements,  this  Agreement 
shall  govern.  By  using  this  CD,  you  agree  to  be  bound  by  the  terms 
and  conditions  of  this  Agreement.  MindView  I nc.  owns  title  to  the 
Content  and  to  all  intellectual  property  rights  therein,  except  insofar  as 
it  contains  materials  that  are  proprietary  to  third-party  suppliers.  All 
rights  in  the  Content  except  those  expressly  granted  to  you  in  this 
Agreement  are  reserved  to  MindView  Inc.  and  such  suppliers  as  their 
respective  interests  may  appear. 

1.  LIMITED  LICENSE 

MindView  Inc.  grants  you  a limited,  nonexclusive,  nontransferable 
license  to  use  the  Content  on  a single  dedicated  computer  (excluding 
network  servers).  This  Agreement  and  your  rights  hereunder  shall 
automatically  terminate  if  you  fail  to  comply  with  any  provisions  of  this 
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Agreement  or  any  of  the  Other  Agreements.  Upon  such  termination, 
you  agree  to  destroy  the  CD  and  all  copies  of  the  CD,  whether  lawful 
or  not,  that  are  in  your  possession  or  under  your  control. 

2.  ADDITIONAL  RESTRICTIONS 

a.  You  shall  not  (and  shall  not  permit  other  persons  or  entities  to) 
directly  or  indirectly,  by  electronic  or  other  means,  reproduce  (except 
for  archival  purposes  as  permitted  by  law),  publish,  distribute,  rent, 
lease,  sell,  sublicense,  assign,  or  otherwise  transfer  the  Content  or  any 
part  thereof. 

b.  You  shall  not  (and  shall  not  permit  other  persons  or  entities  to)  use 
the  Content  or  any  part  thereof  for  any  commercial  purpose  or  merge, 
modify,  create  derivative  works  of,  or  translate  the  Content. 

c.  You  shall  not  (and  shall  not  permit  other  persons  or  entities  to) 
obscure  MindView's  or  its  suppliers  copyright,  trademark,  or  other 
proprietary  notices  or  legends  from  any  portion  of  the  Content  or  any 
related  materials. 

3.  PERMISSIONS 

a.  Except  as  noted  in  the  Contents  of  the  CD,  you  must  treat  this 
software  just  like  a book.  However,  you  may  copy  it  onto  a computer 
to  be  used  and  you  may  make  archival  copies  of  the  software  for  the 
sole  purpose  of  backing  up  the  software  and  protecting  your 
investment  from  loss.  By  saying,  "just  like  a book,"  MindView,  Inc. 
means,  for  example,  that  this  software  may  be  used  by  any  number  of 
people  and  may  be  freely  moved  from  one  computer  location  to 
another,  so  long  as  there  is  no  possibility  of  its  being  used  at  one 
location  or  on  one  computer  while  it  is  being  used  at  another,  j ust  as  a 
book  cannot  be  read  by  two  different  people  in  two  different  places  at 
the  same  time,  neither  can  the  software  be  used  by  two  different 
people  in  two  different  places  at  the  same  time. 

b.  You  may  show  or  demonstrate  the  un-modified  Content  in  a live 
presentation,  live  seminar,  or  live  performance  as  long  as  you  attribute 
all  material  of  the  Content  to  MindView,  I nc. 

c.  Other  permissions  and  grants  of  rights  for  use  of  the  CD  must  be 
obtained  directly  from  MindView,  Inc.  at  http://www.MindView.net. 
(Bulk  copies  of  the  CD  may  also  be  purchased  at  this  site.) 
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DISCLAIMER  OF  WARRANTY 


The  Content  and  CD  are  provided  "AS  IS"  without  warranty  of  any 
kind,  either  express  or  implied,  including,  without  limitation,  any 
warranty  of  merchantability  and  fitness  for  a particular  purpose.  The 
entire  risk  as  to  the  results  and  performance  of  the  CD  and  Content  is 
assumed  by  you.  MindView  Inc.  and  its  suppliers  assume  no 
responsibility  for  defects  in  the  CD,  the  accuracy  of  the  Content,  or 
omissions  in  the  CD  or  the  Content.  MindView  Inc.  and  its  suppliers  do 
not  warrant,  guarantee,  or  make  any  representations  regarding  the 
use,  or  the  results  of  the  use,  of  the  product  in  terms  of  correctness, 
accuracy,  reliability,  currentness,  or  otherwise,  or  that  the  Content  will 
meet  your  needs,  or  that  operation  of  the  CD  will  be  uninterrupted  or 
error-free,  or  that  any  defects  in  the  CD  or  Content  will  be  corrected. 
MindView  Inc.  and  its  suppliers  shall  not  be  liable  for  any  loss, 
damages,  or  costs  arising  from  the  use  of  the  CD  or  the  interpretation 
of  the  Content.  Some  states  do  not  allow  exclusion  or  limitation  of 
implied  warranties  or  limitation  of  liability  for  incidental  or 
consequential  damages,  so  all  of  the  above  limitations  or  exclusions 
may  not  apply  to  you. 

In  no  event  shall  MindView  Inc.  or  its  suppliers'  total  liability  to  you  for 
all  damages,  losses,  and  causes  of  action  (whether  in  contract,  tort,  or 
otherwise)  exceed  the  amount  paid  by  you  for  the  CD. 

MindView,  Inc.,  and  Prentice-Hall,  Inc.  specifically  disclaim  the  implied 
warrantees  of  merchantability  and  fitness  for  a particular  purpose.  No 
oral  or  written  information  or  advice  given  by  MindView,  Inc.,  Prentice- 
Hall,  Inc.,  their  dealers,  distributors,  agents  or  employees  shall  create 
a warrantee.  You  may  have  other  rights,  which  vary  from  state  to 
state. 

Neither  MindView,  Inc.,  Bruce  Eckel,  Chuck  Allison,  Prentice  Hall,  nor 
anyone  else  who  has  been  involved  in  the  creation,  production  or 
delivery  of  the  product  shall  be  liable  for  any  direct,  indirect, 
consequential,  or  incidental  damages  (including  damages  for  loss  of 
business  profits,  business  interruption,  loss  of  business  information, 
and  the  like)  arising  out  of  the  use  of  or  inability  to  use  the  product 
even  if  MindView,  Inc.,  has  been  advised  of  the  possibility  of  such 
damages.  Because  some  states  do  not  allow  the  exclusion  or  limitation 
of  liability  for  consequential  or  incidental  damages,  the  above 
limitation  may  not  apply  to  you. 
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This  CD  is  provided  as  a supplement  to  the  book  "Thinking  in  C++  2nd 
edition."  The  sole  responsibility  of  Prentice-Hall  will  be  to  provide  a 
replacement  CD  in  the  event  that  the  one  that  came  with  the  book  is 
defective.  This  replacement  warrantee  shall  be  in  effect  for  a period  of 
sixty  days  from  the  purchase  date.  MindView,  Inc.  does  not  bear  any 
additional  responsibility  for  the  CD. 

NO  TECHNICAL  SUPPORT  IS  PROVIDED  WITH  THIS  CD  ROM 

The  following  are  trademarks  of  their  respective  companies  in  the  U.S. 
and  may  be  protected  as  trademarks  in  other  countries:  Sun  and  the 
Sun  Logo,  Sun  Microsystems,  Java,  all  Java-based  names  and  logos 
and  the  J ava  Coffee  Cup  are  trademarks  of  Sun  Microsystems;  I nternet 
Explorer,  the  Windows  Media  Player,  DOS,  Windows  95,  and  Windows 
NT  are  trademarks  of  Microsoft. 
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Thinking  in  C:  Foundations  for  Java  & C+  + 

Multimedia  Seminar-on-CD  ROM 
©2000  MindView,  Inc.  All  rights  reserved. 

WARNING:  BEFORE  OPENING  THE  DISC  PACKAGE,  CAREFULLY 
READ  THE  TERMS  AND  CONDITIONS  OF  THE  LICENSE 
AGREEMENT  & WARANTEE  LIMITATION  ON  THE  PREVIOUS 
PAGES. 

The  CD  ROM  packaged  with  this  book  is  a multimedia  seminar 
consisting  of  synchronized  slides  and  audio  lectures.  The  goal  of 
this  seminar  is  to  introduce  you  to  the  aspects  of  C that  are 
necessary  for  you  to  move  on  to  C ++  or  J ava,  I eavi  ng  out  the 
unpleasant  parts  that  C programmers  must  deal  with  on  a day-to- 
day  basi  shut  that  the  C-H- and  Java  languages  steer  you  away 
from.  The  CD  also  contains  this  book  in  HTML  form  along  with  the 
source  code  for  the  book. 

This  CD  ROM  will  work  with  Windows  (with  a sound  system)  and 
the  M ad  ntosh.  H owever,  you  must: 

1.  Install  the  most  recent  version  of  Microsoft's  Internet  Explorer. 
Becauseofthefeatures  provided  on  theCD,  it  will  NOT  work 
with  N etscape  N avigator.  The  I nternet  Explorer  software  for 
both  the  M ad  ntosh  and  Windows  9X/NT  is  induded  on  the 
CD. 


2.  Install  M icrosoft's  Windows  M edia  Player.  Unfortunately  this  is 
only  allowed  to  bedistributed  directly  from  Microsoft's  Web 
site,  so  it  is  NOT  included  on  theCD.  You  will  need  to  goto 
http  ://w  w w .m  i crosoft.eom/w  i ndows/med  i apl  ay»nd  fol  I ow 

the  instructions  or  links  there  to  download  and  install  theMedia 
Player  for  your  particular  platform  (you  may  need  to  find  and 
follow  an  extra  I ink  for  the  Mad  ntosh  version).  Please  note  that 
M icrosoft  someti  mes  changes  the  location  of  Web  pages  on  thei  r 
site  and  in  that  case  you'll  need  to  usetheir  searching  capability 
to  find  the  media  player. 
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At  this  point  you  shouid  beabieto  piay  theiectureson  theCD. 

U si  ng  the  i nternet  Expi  orer  Web  browser,  open  the  f i i e I nstal  I .html 
thatyou'ii  find  on  theCD.Thiswiii  introduce  you  totheCD  and 
provide  further  instructions  about  the  use  of  the  CD. 
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